I've used it for multiple apps at this point and it's been a huge win for me in terms of productivity (I'm also quite enjoying Reagent with ClojureScript so far, but I'll withhold judgement on that for now). Trying to apply simple FRP-style abstractions over state changes like Signals becomes infinitely more tractable in React, where components are just functions that return data (as opposed to most frameworks, like Angular, with their very effectful controllers and other code).
Also, having worked with both Angular and React alongside less experienced developers, I've noticed developers in general doing a lot less stupid shit with React (not to say none, just less). Angular doesn't have many strong philosophies about programming, so it's largely up to the programmer to make good decisions rather than have the framework make the right thing feel right - the latter, in my opinion, being what growing developers need.
My sample sizes have been limited though, so take this advice with a grain of salt. Also, I picked on Angular because that's the other framework I have a reasonable level of experience with, but you could substitute most frameworks in its place.
EDIT: One thing I'm still missing is Flux. I tend to use React alongside PouchDB, and thus haven't really encountered a need for Flux, but even then - I think I simply don't get it. I mean, it's just a convoluted event bus, right? What's the big deal? I don't mean to undermine the efforts of Facebook's engineering team(s), I rather feel like there must be something about the Flux architecture that I'm missing, that somehow makes it more valuable than a simple event bus.
The point of flux is one way data flow. Your data lives in ONE place (the "store"), and then it's fed into your views, which render it in a deterministic fashion. User interaction triggers actions, which circle back around to modify the data in your stores. Data should only be modified by actions, and views should only change when your data does.
There's a lot of advantages to this (in terms of performance, but much more importantly, in terms of being able to reason about your code). You could think of it as an event bus, and you might even implement it with one, but that's an implementation detail. In terms of your actual code, your store will list which actions it wishes to be respond to, your views will list which stores they want data from, and you'll have some UI elements that trigger actions. Your view doesn't "know" about events; it knows that it'll be rendered with the data it needs passed in as props, and re-rendered with the new data it needs.
You're probably using PouchDB more or less as a store. If not, you probably should be, and it would be trivial to write a very lightweight wrapper around it to tie it into your existing flux implementation of choice. What flux is trying to get you to avoid is some sort of ugly ball of ad hoc AJAX calls and local component state. PouchDB is already pushing you the same direction. (Which is probably why you don't see a point.)
Okay thanks, that actually clears things up a lot. Funnily enough, I found myself using this exact pattern in ClojureScript yesterday, using a ratom as my store and having what I suppose I should call "actions" which (may make HTTP calls and) update the data.
I haven't used it myself yet, but I'm itching to! I love Reagent and I'm very interested in FRP, especially the proposition that it might simplify the code a great deal if your app is above a certain threshold of complexity.
Honest answer? It seemed simpler. I haven't used Om yet so I won't try to compare the two, but Reagent presents very simple interface. Components are just functions which emit Hiccup. Reagent's ratoms are, I'm told, much like Om's Cursors, but different in a way that I haven't investigated enough to understand. Looking at the READMEs for the two projects, Reagent just seemed more approachable to me.
While I've really enjoyed working with Reagent (I haven't encountered any real deficiencies, though that may just indicate I haven't used it enough), I'm totally open to being convinced in favor of Om.
Yea, going through Reagent and Om's tutorials side-by-side, Reagent seems way simpler. I'm new to Clojure and Clojurescript, so I figure learning Reagent would provide a base where I could then delve into Om.
Are you using Reagent in production or just for personal projects?
Just for personal use right now, though I'm currently implementing something on my own time that I'm hoping will prove valuable enough to be used at work (thus introducing ClojureScript to my company). A bit underhanded, but I genuinely think that the system I have going with CLJS so far is leagues ahead of what we'd get with an Angular implementation (which we used for the other side of our front-end).
Also, having worked with both Angular and React alongside less experienced developers, I've noticed developers in general doing a lot less stupid shit with React (not to say none, just less). Angular doesn't have many strong philosophies about programming, so it's largely up to the programmer to make good decisions rather than have the framework make the right thing feel right - the latter, in my opinion, being what growing developers need.
My sample sizes have been limited though, so take this advice with a grain of salt. Also, I picked on Angular because that's the other framework I have a reasonable level of experience with, but you could substitute most frameworks in its place.
EDIT: One thing I'm still missing is Flux. I tend to use React alongside PouchDB, and thus haven't really encountered a need for Flux, but even then - I think I simply don't get it. I mean, it's just a convoluted event bus, right? What's the big deal? I don't mean to undermine the efforts of Facebook's engineering team(s), I rather feel like there must be something about the Flux architecture that I'm missing, that somehow makes it more valuable than a simple event bus.