On Wednesday, October 29, 2014 3:48:35 PM UTC-5, Scott Nelson wrote: > When using Om's cursors I had a number of top level entries in the app state > (i.e. things like current route, error messages, current user, etc.). Mike, > how are you modeling these kind of singleton objects as DataScript entities? > Or are you using separate atoms for this kind of thing?
There are a couple of ways to do this. You can create separate entities in Datascript to store these things. This is generally the approach I used and I created some helper functions to more easily setup and track these "singleton" entities. But I was evolving towards the second approach, as my app grew. The second approach is to decorate existing entities with additional attributes. For something like current-user, assuming you already have a list of users in your DB, you could add a :user/selected boolean attribute. For single selection you have a DB fn that resets all users to 'false' except the selected one, but you could change that to multi-selection simply by not resetting the flag on other users. It's more work on a case by case basis, but if you start thinking in abstractions like this you can create generic DB functions that can be applied across a wide range of entities. Abstractions like "selectable", "hideable", "toggleable" can be reused in many parts of most UIs. I'm speaking in past tense, because I have temporarily had to stop using this approach in my app. As my app grew I began to notice substantial lag at times running on my target mobile devices. It was never a problem testing on a desktop browser, but of course mobile browsers have much less horsepower. The problem stemmed from a few things: 1) the binding code was very inefficient 2) each reagent component simply binds whatever state it needs, so for example if 5 different components need the user list, they each bind their own r/atom. 3) the combination of 1 and 2 means several dozen inefficient binding listeners running after every transaction, which became noticeable on mobile. I had a couple of choices - remove Reagent and use Quiescient or React directly for rendering, as tonsky did in his demo app, or remove Datascript and continue to use Reagent. I chose the latter, with the intention to be able to go back to using Datascript once I work through the problems. I think the key to fixing this is this feature: https://github.com/tonsky/datascript/issues/32 which fortunately has now been implemented (just noticed that when I popped over to grab the link). Having transaction metadata should allow me to optimize the binding code significantly. Since I can't risk these experiments in my production app at this point, I'll probably pull out code and create a demo app I can experiment on and share, then when I am confident that I have the binding code optimized I can re-introduce Datascript to my production app. I'm in the process of setting up my blog and my goal is to have the first post or two on this finished before the Conj, so look for something over the next 2-3 weeks. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
