Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic.
I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what "state" your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. On Thu, 14 May 2015 22:34 Jamie Orchard-Hays <jamie...@gmail.com> wrote: > I'm still in the early stages of digesting Javelin, but one idea I keep > having is using it locally in components to make subscriptions that are > otherwise global using reframe. > > On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays <jamie...@gmail.com> > wrote: > > No kidding. I have this long blog post germinating in my head about my > experiences with Om and re-frame now that I've developed a reasonably-sized > app in each. Problem is, I have no time to write it. One thing I've come to > appreciate about Om over Reagent is that despite it being more verbose, > it's always clear where you are WRT the React lifecycle and state. Reagent, > being less formal, lends itself to some confusion over what's happening > where. > > In general, I agree with some comments I've seen in this group recently > that we really have a long way to go with rich client web apps. It's still > way too time-consuming, painful and not formalized enough, even with the > awesome tools we have around already. Simple *and* easy is the brass ring. > > > On May 14, 2015, at 3:35 PM, Colin Yates <colin.ya...@gmail.com> wrote: > > +1 I keep thinking "yeah, this is the stack I will use, let's invest in > this" then something new comes along. Not good for those of use affected > with "grassisalwaysgreeneritus" :). > On 14 May 2015 19:39, "Jamie Orchard-Hays" <jamie...@gmail.com> wrote: > >> This is really interesting stuff. I'd looked over Hoplon a year ago and >> didn't use it as it wasn't React-based. I really liked the >> spread-sheet/cell metaphor. I wish I had more time to explore all of these >> libs! :) CLJS is enjoying quite a Cambrian explosion of interesting >> libraries. >> >> Jamie >> >> On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk <fer.ob...@gmail.com> >> wrote: >> >> > Jamie, exactly, I took re-frame (it's awesome!) and replaced >> subscriptions mechanism with Javelin cells. I like Javelin, it allows >> elegant and succinct data coordination. See todomvc example in the amper >> and re-frame repos for comparison. >> > >> > Also I've replaced Reagent with Om because of my internal needs, but >> re-frame architecture is View-agnostic in its heart, and I've implemented >> it in ampere. Now it includes only Om adapter, but more to come with >> examples (I plan to make todomvc views.cljs port for every supported View >> library). Hoplon does not require any adapter at all, for example ;-) >> > >> > -- >> > 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. >> > > -- > 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. > -- 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.
