On Saturday, April 26, 2014 2:07:57 AM UTC-4, David Nolen wrote: > This is not completely accurate. Cursors abstract away the particular state > strategy. Even with DataScript you will want some indirection for reusable > components. I suspect widgets will take entities or composites and in order > for rendering to be efficient you will want entity caching. > > > On Saturday, April 26, 2014, Nikita Prokopov <[email protected]> wrote: > > суббота, 26 апреля 2014 г., 1:31:52 UTC+7 пользователь Daniel Neal написал: > > > Is this something that could potentially work *with* Om or is it going down > > a different road? > > > > > > I'm really enjoying Om for client side work but totally love the idea of > > being able to do database-like queries over the application state as you > > describe. > > > > I thinks DataScript is something that can be used instead of Om cursors. Of > course you can mix, it’s just a library. But for proper integration cursors > will be just a dead weight, so it would be easier to integrate with pure > React or some thin wrapper around React like Quiescent. > > > > > But that’s just my opinion, David already started to toy with Om integration > :) > > > > -- > > 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.
Very interested to see how this pans out. Being able to write real queries for views is a big leap forward. In a current project I'm dynamically filtering on 3 criteria and then sorting 5000+ items, and while clojurescript offers a pretty rich toolset, a datalog query would be a pretty significant simplification of that process. As far as Om integration, I could see separating concerns a little being a possible solution. If you keep the parameters for your queries in app state, and pass the database as a shared cursor, any change in app state that would change the query a component uses to retrieve it's view of the database would cause a rerender. The issue would become keeping the app in sync with database changes. You could just trigger a root rerender on any db change, but the whole point of Om is that you don't want to rerender the entire app on change, just the components with affected cursors. A little wrapper might do the trick. What if you mediate all component queries to the database, and cache a list of returned entities. Anytime any of those entities change, the component should be rendered (you could even implement more advanced update to the query result instead of triggering a new query). Anytime a new entity is added to the database, check if it would be included in the result of any component query, and mark those components as dirty. Thoughts? -- 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.
