Actually, I'm interested in local transitions (cell=) rather than local state. That is, a view may be interested in transitions that only apply to itself. I like the idea of encapsulating those transitions into the view itself. re-frame's subscriptions are inherently global, at least to whichever namespaces have required the subscriptions. This offers better encapsulation as I understand them.
Jamie On May 14, 2015, at 8:27 PM, Daniel Kersten <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 [email protected]. >>> > To post to this group, send email to [email protected]. >>> > 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
