[ClojureScript] ANN: DataScript, in-memory database and datalog queries in ClojureScript
Hi! I’m glad to announce my new library, DataScript. It’s an open-source, from-the-scratch implementation of in-memory immutable database aimed at ClojureScript with API and data model designed after Datomic. Full-featured Datalog queries included. Library is here: https://github.com/tonsky/datascript Also check out this blog post about why you may need a database in a browser: http://tonsky.me/blog/decomposing-web-app-development/ Feedback welcome! -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Tao, two-way data binding between edn and browser history (with Om in mind)
On Apr 11, 2014, at 3:28 PM, Dylan Butman wrote: > Wrote a very small library on top of secretary that allows for two way data > binding between edn (think application-state) and browser history. > https://github.com/pleasetrythisathome/tao > Thoughts, comments, pull requests, greatly appreciated! Very cool, thanks for sharing! I have some questions/thoughts: Would it possible (and a good/OK/reasonable idea) to keep the routing state in the component local state of the Om root component, instead of the app-state? If so, would it also be possible to initialize things like nav-chan, init-history, and deftao routes in the iWillMount implementation of the Om root component? -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Om: How to conditionally update two cursor keys?
I have a cursor that contains a map of two keys, :key1 and :key2. I would like to do the following: 1. Read the value of :key1 2. Use this value to derive a new value 3. Check if the new value meets some conditions * If yes, set the value of :key1 to the new value. Additionally, update another value held in :key2. * Otherwise, don't make any updates to :key1 or :key2 Whats the best way to do this kind of operation? Is it safe to deref the value of :key1 before calling transact!/update! or could this cause a concurrency bug? I'm sure how to do this all contained in a single transact! function. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: Om 0.6.1, moving towards independently addressable components
To what extent are the issues you are addressing with Om and state/cursors related to ORM-like problems? In a previous post: https://groups.google.com/forum/#!topic/clojurescript/88u7kcomnUA Here you mentioned that in Om you have a "database-like system + time model". That made me think about the nasty ORM issues with databases and how cursors could be thought of as falling into the same problem set. Maybe there is something that can be learned (avoided?!) in Om. The component <-> app state mapping(s) looks to be a fairly difficult problem. You probably already have this figured out so I'm interested to see your solution. I'm especially interested to see how your solution will work with a large state/DOM model and being able to support "progressive reveal". In our domain we have a very large data set that if fully rendered in the DOM would consume too much time/space. We have tried to solve this problem by only rendering those portions of the state into the DOM that are visible to the user so as to avoid doing work that won't ever be needed. We provide a means for the user to navigate into the data set and render only as much as is necessary but our solution is clunky... It would be nice if Om is able to help us solve that problem. While we aren't using it yet, I have been experimenting with Om and am stumbling into the same state/data management questions as other have. In particular, there is the notion of application data (e.g. user profile) that represents the underlying data model for the domain (often stored on the server w/ portions cached on the client) and then there is the non-durable/temporary/non-shared client state that reflects the user's interaction and component view of that application data (e.g. the user has partially edited their profile's phone number.) Maybe Om already does all that and I just don't "get it"... TBD. BTW - thank you for all your hard work on Om. Alan On Thursday, April 24, 2014 10:03:37 AM UTC-7, David Nolen wrote: > > Om 0.6.1 significantly changes how component local state works - we now > rely on React's forceUpdate to update components that use local state. This > is a significant change so I would like people test this out on their > existing code bases as soon as possible. > > The immediate benefit is that components now use `=` for the > shouldComponentUpdate logic instead of `identical?`. This means > considerably more flexibility with regards to what a component may receive > without taking a performance hit with respect to rendering. Even more > importantly it's a big step towards independently addressable components. > > What are independently addressable components? Currently many people > struggle with the fact that parent components must take all the data > associated with their children. This often results in a tight coupling that > is not ideal for real applications. The next few releases of Om will be > focused on providing a sensible solution to this issue without backing away > from the existing efficient time travel capabilities. > > Feedback welcome! > > http://github.com/swannodette/om > > David > -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: Om 0.6.1, moving towards independently addressable components
All looks good here - a drop-in replacement. :-) Independently addressable components will be a very nice enhancement for us. I look forward to it. Cheers, Kris On Thursday, 24 April 2014 18:03:37 UTC+1, David Nolen wrote: > > Om 0.6.1 significantly changes how component local state works - we now > rely on React's forceUpdate to update components that use local state. This > is a significant change so I would like people test this out on their > existing code bases as soon as possible. > > The immediate benefit is that components now use `=` for the > shouldComponentUpdate logic instead of `identical?`. This means > considerably more flexibility with regards to what a component may receive > without taking a performance hit with respect to rendering. Even more > importantly it's a big step towards independently addressable components. > > What are independently addressable components? Currently many people > struggle with the fact that parent components must take all the data > associated with their children. This often results in a tight coupling that > is not ideal for real applications. The next few releases of Om will be > focused on providing a sensible solution to this issue without backing away > from the existing efficient time travel capabilities. > > Feedback welcome! > > http://github.com/swannodette/om > > David > -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Should the Om tutorials use update! when possible?
Use transact! if you need to operate on the previous value in order to update, use update! if you want to replace the previous value. No plans to change the tutorials as far as this is concerned. David On Thu, Apr 24, 2014 at 2:50 PM, Paul Butcher wrote: > Having quite correctly had my wrist slapped by David for opening a ticket > to ask a question (sorry David - that arose from broken logic following my > discovery that there’s no such thing as a pull request for wiki pages - I > didn’t want to just change the wiki pages without asking first, and for > some reason I thought that a ticket would be the next-best thing) I’ll ask > the question here. > > There are a number of places where the Om tutorials use transact! where > they could use update!. For example, in the basic tutorial: > > (defn handle-change [e text owner] > (om/transact! text (fn [_] (.. e -target -value > > > could be: > > (defn handle-change [e text owner] > (om/update! text (.. e -target -value))) > > > The fact that the tutorials consistently use transact! leads me to wonder > whether there’s a good reason for this (and that I should do the same in my > own code). Although that then raises the question of why update! is in the > Om API at all. > > Alternatively, would it make sense to modify the tutorials to use update! > when possible? Which would be (to my eye) easier to read and avoid others > from facing the same dilemma? > > -- > paul.butcher->msgCount++ > > Silverstone, Brands Hatch, Donington Park... > Who says I have a one track mind? > > http://www.paulbutcher.com/ > LinkedIn: http://www.linkedin.com/in/paulbutcher > Skype: paulrabutcher > > Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel > http://pragprog.com/book/pb7con > > -- > 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 clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. > -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Should the Om tutorials use update! when possible?
Having quite correctly had my wrist slapped by David for opening a ticket to ask a question (sorry David - that arose from broken logic following my discovery that there’s no such thing as a pull request for wiki pages - I didn’t want to just change the wiki pages without asking first, and for some reason I thought that a ticket would be the next-best thing) I’ll ask the question here. There are a number of places where the Om tutorials use transact! where they could use update!. For example, in the basic tutorial: (defn handle-change [e text owner] (om/transact! text (fn [_] (.. e -target -value could be: (defn handle-change [e text owner] (om/update! text (.. e -target -value))) The fact that the tutorials consistently use transact! leads me to wonder whether there’s a good reason for this (and that I should do the same in my own code). Although that then raises the question of why update! is in the Om API at all. Alternatively, would it make sense to modify the tutorials to use update! when possible? Which would be (to my eye) easier to read and avoid others from facing the same dilemma? -- paul.butcher->msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel http://pragprog.com/book/pb7con -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] ANN: Om 0.6.1, moving towards independently addressable components
David, This is exciting - I know you've been thinking about how to solve this problem for weeks, and I'm anxious to see how things evolve. I have several little POC apps I've done over the last couple months, and I've just started pulling the bits and pieces together into the "real" app for a real-world project I'm working on. So I'll be able to give you feedback on the changes as I'm now working on this full-time. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] ANN: Om 0.6.1, moving towards independently addressable components
Om 0.6.1 significantly changes how component local state works - we now rely on React's forceUpdate to update components that use local state. This is a significant change so I would like people test this out on their existing code bases as soon as possible. The immediate benefit is that components now use `=` for the shouldComponentUpdate logic instead of `identical?`. This means considerably more flexibility with regards to what a component may receive without taking a performance hit with respect to rendering. Even more importantly it's a big step towards independently addressable components. What are independently addressable components? Currently many people struggle with the fact that parent components must take all the data associated with their children. This often results in a tight coupling that is not ideal for real applications. The next few releases of Om will be focused on providing a sensible solution to this issue without backing away from the existing efficient time travel capabilities. Feedback welcome! http://github.com/swannodette/om David -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
