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.

Reply via email to