There was some more work done on supporting query change binding in datascript https://github.com/tonsky/datascript/pull/12
and there's also a larger project https://github.com/vitalreactor/derive that aims to provide similar functionality on top of either their own in memory db NativeStore or on top of datascript. There was a larger thread about it https://groups.google.com/forum/#!searchin/clojurescript/derive/clojurescript/WCz57-k8leY/cdLHHpBJ6qEJ before ref cursors. Next rainy day I want to sit down and write parallel implementations of something like a chat system using Om w/ ref cursors Datascript w/ Derive Unmerged query watching Reagent w/ multiple atoms Maybe a port of tonky's chatting cats example? Any thoughts on other combinations that might be useful in a side-by-side comparison? On Thursday, October 30, 2014 2:52:23 PM UTC-4, Mike Haney wrote: > 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.
