This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
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?
You should prefix your paths with / to make them absolute within the server.
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).
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.
Erm, sorry -- I meant datascript db. Posh actually watches the datom changes and will intelligently re-run subscriptions.
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.
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.
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.
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.
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.
But I see your point. I guess I can use posh as well.
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.