Clojurians Log v2
re-frame
Thanks!
What I did is to make a subscription to check if the database change.
So all my queries have a layer 3 subscriptions.
And since checking for equality of immutable data structure is cheap, it is fast enough.
Hence, queries will not be run again, unless the datascript db was modified.
Obviously, you might not want to have all your state variables in a single datascript database.
My issue was that my app started to have a lot of query logic and I was starting to repeat the same code all the time, and it become ever more convoluted when I had to make joins operations.
So to answer the critic: no, your queries will not be re-run whenever app-db change thanks to 3 layers subscriptions.
I've an app that needs to make a websocket connection for fetching data. I'm using re-frame-async-flow-fx with great success to orchestrate my initial app boot. Reitit is my router. Now, I have to handle cold-start on nested routes like /app/a-thing/1/a/nested/thing/42. The reitit controller functions dispatch "get my data" events when the route is loaded, but this happens in parallel to the boot flow, so often the boot isn't complete by the time the controller event fires, resulting in a failure to get data. Any tips on how to resolve this?
For now I've been re-queuing the controller event in the failure handler with dispatch-later 😕
Hmm, but then the boot flow would be triggered by the user just navigating in the app even in non-cold start scenarios
You can use a flag of sorts to check if it's a cold start or not.
Also I can't miss this opportunity to mention kee-frame. :) Maybe it'll be useful to you as well.
A first-boot flag would work I suppose, but the more I think about it I think this can be solved by solving the general case of retry-handling when the ws connection fails. I'm using sente, so auto reconnecting is built in, but when events fail due to a bad socket, I need a way to retry them once th connection is back up. Hm but you probably don't want to retry every request.
Make reitit start the boot flow?
Thanks to @olivergeorge @mikethompson and others who https://github.com/day8/re-frame/issues/639 we have a new re-frame release v1.1.0 with a new :fx effect. Read more at https://github.com/day8/re-frame/blob/master/docs/api-builtin-effects.md#ordering
On a page refresh I am losing certain items from the app-db causing my page to blow up, are there any best practices around persisting things? I am also confused why somethings stick around and others vanish.
Nothing should stick around in app-db by itself. Something somehow loads that data into app-db from somewhere.
With that being said, the usual place to persist things client-side is Local Storage.
Essentially I have a list of tasks, when you select a task it opens a page that is subscribed to a task object in the app-db and the event sets the selected task to that. If I want refresh to not, blow up should I also be putting the task into local storage as well so if it is not already in app-db, I can pull it in?
If you're writing an SPA, why do you refresh the page? Why not just load data via XHR/WebSocket and use it while also updating the URL in the browser address bar?
That is what I am doing, but during development I am refreshing the page to see my changes and was wondering what to do if the user refreshes the page during some workflow?
> I am refreshing the page to see my changes You should change your development setup so that the page is re-rendered (not refreshed!) automatically when you make a change. Figwheel and Shadow-cljs support this. > was wondering what to do if the user refreshes the page during some workflow It depends on the workflow. Take what you want to achieve, find a conceptually similar platform that's used by actual users, and see what they've done. For example, GMail doesn't save anything but drafts. So a draft is part of its persistent state, but e.g. current email filter or even current app section (like inbox or settings) are not.
Okay sweet, will check that out and sounds good will think that through! Thanks!
NP, good luck.