In the case of global app state combined with a state machine, where would the URL be stored ? Should it be considered a trigger/event of the state machine ? Should it be stored in the state as any other data ?
> Le 15 mai 2015 à 03:22, Marc Fawzi <[email protected]> a écrit : > > Thanks Brutha! :) > > Sent from my iPhone > >> On May 14, 2015, at 6:11 PM, Jamie Orchard-Hays <[email protected]> wrote: >> >> Speaking of Cambrian Explosion, I saw in the latest LispCast a link to a new >> React CLJS lib from weavejester called Brutha: >> https://github.com/weavejester/brutha >> >> Jamie >> >>> On May 14, 2015, at 8:54 PM, Jamie Orchard-Hays <[email protected]> wrote: >>> >>> 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. > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to a topic in the Google > Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. > To unsubscribe from this group and all its topics, 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.
