Is Fulcro opionated about where it persists browser state and how? Does it handle the js/history api for you? Does it maybe store state in it?

@drewverlee Fulcro is opinionated about browser state which is in fact the foundation of the whole client system. It does not directly handle js/history, but is trivial to integrate with a library that does. Your best bet to understand the system quickly is the “Talk” video link in the channel header. Part 15 Sessions and UI Routing of the tutorial series goes into it in some depth.

I suppose i'm trying to understand the advantages to of storing state using the history api. I know its possible to store application state using the history api. Though im not aware of exactly how thats backed. http://html5doctor.com/history-api/ > These history items can also hold data that you can later extract to restore the page state. Moreover, i'm trying to figure out if there is something fundamental about managing state that. I thought i would look into what Fulcro was doing as i see it as innovate approach but sensible built on practical foundations.

@drewverlee so there is a lot of complexity around making a back button work in any kind of real application. You can move the client’s state around willy-nilly very easily, but making sure the server understands where you are is, well, up to you since it is your server. In terms of moving around in time: Fulcro makes that trivial…just save/restore the state database out of the central state atom.

Most browser APIs need your state to be serializable in some sense. So, you do have to be careful not to throw stuff in FUlcro app state that cannot be turned into something a browser can handle. Transit with metadata support turned on will do it, though they don’t recommend using that for long-term storage of any kind…but I would not characterize history like that as “long term” since it would not persist across version changes

Thanks Tony and thosmos. So Fulcro doesn't explicitly set state via the history api. But there isn't anything fundemental about saving state that way. I assume that the api is just seralizing the js-object/state each time into a log that it knows how to read from. Which is supported by this in the mozilla docs: > Because Firefox saves state objects to the user's disk so they can be restored after the user restarts the browser, we impose a size limit of 640k characters on the serialized representation of a state object However, there isn't any fundamental about using that for saving state or for communicating back to the server what state the client is in. It's probably just a widely supported and understood approach. I have been confused about the relationship between the URL, client state and server to client state. To me, the URL's most important role is identifying the protocol, and ip address and port. That is enough to know how to talk to the server, but doens't say anything about what you say to it. I'm trying to understand if the rest, the path params and query params are also fundemental building blocks (possible due to legacy reasons on the server or browser). Or if that part cans imply be ignored and swapped out for a new from of communicating state across the browser and server. I know whats a mouth full! I'm never sure where such discussions are welcome or distracting!

@drewverlee I see you’re interested specifically in saving state into the browser’s history. I haven’t interacted with that directly. Mostly I’ve seen libraries used like pushy which itself uses Google Closure’s goog.history library: https://github.com/clj-commons/pushy/blob/master/src/pushy/core.cljs

@drewverlee you might also find interesting reitit’s frontend library which interacts directly with the js/history: https://github.com/metosin/reitit/blob/master/modules/reitit-frontend/src/reitit/frontend/history.cljs

As for your more philosophical 😉 ideas about the URL, I generally think about it via Tim Berners Lee’s original notion that a URL is intended to uniquely identify a resource of some kind. In the case of modern client-side apps, I generally think of the core URL as the path to the “page” or main visible component and query params can be added to it to uniquely describe sub-components or states that are visible. For example, you might have a component that has a map and charts at http://site.org/map and then as you add a few sites to the map, or change the time domain of the charts, these can be described with query params: http://site.org/map?sites=1,2,3&dateStart=2017-01-01&dateEnd=2019-01-01. Since a SPA (single page app) is in control of the URL, as you add/remove sites to the map, all you’re doing is updating the URL so that if the user copies it they can come back to that view or share it. But this requires that when you first load the app, you actually use that info to load the components and values to match. Is this even what you’re asking?

as you update the history you could just store the URLs or perhaps you could store a structured form instead. It’s really up to you what you want to do.

you could choose to have the server handle the query params and pre-generate a client database that has exactly the data needed to satisfy the URL, or you could just load a “blank” client app db and make any data loads needed then.

That is what I'm talking about. Thanks @thosmos. That explanation makes sense to me.