re-frame

https://github.com/Day8/re-frame/blob/master/docs/README.md https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
2020-08-24T06:11:40.054900Z

Thanks!

2020-08-24T06:12:05.055700Z

What I did is to make a subscription to check if the database change.

2020-08-24T06:12:25.056300Z

So all my queries have a layer 3 subscriptions.

2020-08-24T06:12:44.057Z

And since checking for equality of immutable data structure is cheap, it is fast enough.

2020-08-24T06:15:51.058200Z

Hence, queries will not be run again, unless the datascript db was modified.

2020-08-24T06:16:53.059400Z

Obviously, you might not want to have all your state variables in a single datascript database.

2020-08-24T06:20:10.062Z

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.

2020-08-24T06:21:44.063500Z

So to answer the critic: no, your queries will not be re-run whenever app-db change thanks to 3 layers subscriptions.

Casey 2020-08-24T06:37:54.064700Z

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?

Casey 2020-08-24T06:39:04.065700Z

For now I've been re-queuing the controller event in the failure handler with dispatch-later πŸ˜•

Casey 2020-08-24T07:23:49.066Z

Hmm, but then the boot flow would be triggered by the user just navigating in the app even in non-cold start scenarios

p-himik 2020-08-24T07:29:35.066300Z

You can use a flag of sorts to check if it's a cold start or not.

p-himik 2020-08-24T07:31:55.066500Z

Also I can't miss this opportunity to mention kee-frame. :) Maybe it'll be useful to you as well.

Casey 2020-08-24T07:39:54.066700Z

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.

p-himik 2020-08-24T06:40:13.065800Z

Make reitit start the boot flow?

Casey 2020-08-24T07:23:49.066Z

Hmm, but then the boot flow would be triggered by the user just navigating in the app even in non-cold start scenarios

p-himik 2020-08-24T07:29:35.066300Z

You can use a flag of sorts to check if it's a cold start or not.

p-himik 2020-08-24T07:31:55.066500Z

Also I can't miss this opportunity to mention kee-frame. :) Maybe it'll be useful to you as well.

Casey 2020-08-24T07:39:54.066700Z

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.

superstructor 2020-08-24T09:13:22.068100Z

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

6πŸ‘
kenny 2020-08-24T15:03:45.069200Z

Erm, sorry -- I meant datascript db. Posh actually watches the datom changes and will intelligently re-run subscriptions.

Grant Isom 2020-08-24T15:37:32.070400Z

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.

p-himik 2020-08-24T15:44:31.070500Z

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.

Grant Isom 2020-08-24T15:58:03.070700Z

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?

p-himik 2020-08-24T15:59:57.070900Z

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?

Grant Isom 2020-08-24T16:00:48.071100Z

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?

p-himik 2020-08-24T16:06:36.071300Z

> 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.

1
Grant Isom 2020-08-24T16:07:38.071600Z

Okay sweet, will check that out and sounds good will think that through! Thanks!

p-himik 2020-08-24T16:07:51.071800Z

NP, good luck.

2020-08-24T17:14:00.074100Z

Fair point! I was also concerned, but then I think re-frame only recompile subscriptions that are relevant to the current view. So you would need to run the queries anyway?

kenny 2020-08-24T17:14:56.074400Z

Every time you transact data to Datascript, every single DS query will need to re-run even if the transaction did not affect the query.

2020-08-24T17:17:30.077Z

Even if you don’t dereference to the subscription where the queries defined? Anyways, you can circumvent the problem by having multiple datascript datastore, posh forces you to have a single one.

2020-08-24T17:18:11.078100Z

But I will test whether all subscriptions are re run when if you transact.

kenny 2020-08-24T17:19:06.078500Z

If it is not in the view, it won't rerun. In a view with subscriptions, it is highly unlikely that a single DS transaction would affect every single subscription in the given view.

2020-08-24T17:19:48.079400Z

Yes, which minimise the risk of performance issues right?

kenny 2020-08-24T17:22:04.080200Z

No. Take this example... A view is showing the a user's email and a list of products. If you transact any data to Datascript, even if the data isn't relevant to your current view (e.g., you're updating some DS data behind the scenes or storing some internal data), every subscription in your current view will rerun. In a worst case scenario, you'd store the data from an input in DS. This would cause every single query to rerun with each keystroke.

2020-08-24T17:33:30.083200Z

Fair point. To that I answer: you can isolate the data for an input in a different DS in your re-frame app. Reposh forces you to have a single datastore.

2020-08-24T17:39:19.084100Z

But I see your point. I guess I can use posh as well.

2020-08-24T17:42:53.087500Z

I think my biggest issue was that re-posh does not integrate well with re-frame, the disadvantage of this method is that you need to manually partition the different DS databases inside your re-frame DB, and this will solve the performance issue.