Fork me on GitHub

I noticed in my re-frame app that when I refresh a view that's mapped to a URL that has multiple params like /view/123 versus one that's like /path the app tries to look for the compiled js in the new path e.g. view/123/js/compiled/app.js instead of js/compiled/app.js and so I get a 404 error, any idea how to fix this?

Pavel Klavík04:08:13

You should prefix your paths with / to make them absolute within the server.

👍 6
David Pham19:08:55

I recently spoke about composing datascript and re-frame together. I have been playing with it for a few weeks and I am completely positive that you can compose the two libraries without any obvious issues for now. I wrote a quick summary on my solution (obviously might not be perfect). The benefit from wrapping datascript inside re-frame, for me, was to keep all the re-frame and application state concept, but still leverage all the query capabilities of datalog. I wrote a small example here:


The big downside to this approach is that it will need to re-run all DataScript queries every single time the app db changes. For a small app this might be okay. Anything of size, would likely need something more efficient (e.g., posh).

David Pham06:08:05

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

David Pham06:08:25

So all my queries have a layer 3 subscriptions.

David Pham06:08:44

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

David Pham06:08:51

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

David Pham06:08:53

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

David Pham06:08:10

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.

David Pham06:08:44

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


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

David Pham17:08:00

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?


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.

David Pham17:08:30

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.

David Pham17:08:11

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


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.

David Pham17:08:48

Yes, which minimise the risk of performance issues right?


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.

David Pham17:08:30

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.

David Pham17:08:19

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

David Pham17:08:53

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.