Fork me on GitHub

@erik_price: The same parameters are passed to the outer function as are passed to the inner function. The outer is called only once ever (in the first attempt to render). The inner is called each time the component is rendered (including the first time). From Reagent's point of view, your outer and inner functions are just renderers for a component. The parameters passed in to a renderer are the "props". When a "parent" Component rerenders a "child" it may pass into a new set of props. If the props are different to last time, then the renderer is called again, with the new props. When a rerender is called, it will be the inner function getting called again, with fresh props.


I'm a bit dissatisfied with my answer above, so I've added an appendix explaining some of the mechanics ...


Tell me if that works for you.


mikethompson: I can see advantages of reagent over om very clearly; are there disadvantages that people have pointed out? I just don't understand why people are still using om. They are, so I must be missing something. I asked in #C06DT2YSY but no answer so far simple_smile


@mbertheau: Om has a very nice View State history feature built-in, and Om Next “natively” support Datomic for state. This is pretty cool in my point of view, but not a deal breaker for my use of reagent (at least not yet) (sorry to intervene).


I can see datomic, absolutely. View State history - that's undo like ?


@mbertheau: re-frame has undo to. In fact, it has a very flexible undo pattern, if you need it.


@mikethompson: I'm using re-frame already! I like it. I just wonder about om simple_smile


To be honest I never understood what OM had going for it over reagent. Back at the beginning of 2014 when I started this journey both frameworks came out together, so i evaluated them both and it seemed clear to me that reagent was better. This was a harrowing decision at the time, because EVERYONE seemed to be choosing OM. I kept looking back at OM and wondering "what am I missing?".


Then, a month later, I'd have another mini crisis and wonder all over again what I was missing


But every time I looked, I personally found reagent better.


Hence that's where I am


So I personally can't give you any good reason to go with OM. I think its success is entirely to do with it being David Nolen's project, and he's obviously a very high profile, important and influential person. Had reagent been his project and OM someone elses, I don't think OM would get the slightest attention.


So I have fairly strong opinions on the matter theses days. But ... I assure you I was wracked by uncertainty at various times in early 2014 when I was trying to choose simple_smile


@mikethompson: Thank you for that insight simple_smile


I tried both projects, Om seemed as an easier starting point for clojurescript beginner. That was before I discovered re-frame’s reagent documentation


I think reactions and concept of 1-form up to 3-form type components can be too much for beginning clojurescript devs


Also Om will have om-next soon-ish, which can be a major selling point to switch to Om again. We’ll see.


But I agree that Om's popularity was fuelled by David’s fame


I always thought Form-1 and Form-2 was pretty easy. I thought the learning curve with OM was pretty steep. The moment you started using om for anything non trivial, you had to understand core.async, and lifecycle funcs ... a lot. The intermediate tutorial charged straight in.


I do remember staring at this piece of om code at one point (under Example):


I thought as I looked at it "If that is supposed to be the recomended way of doing something, then OM is not for me."


That was a fairly pivotal moment for me. (Although as I said above, I kept going back and trying to like it)


Hm, somehow missed that thing, I was always interested in client side, the sync glue was never much interesting to me. Om’s single app-state atom approach was pretty simple. Didn’t have to use anything fancy for simple SPA


and syncing of the atom to server side was always as trivial as dumping whole app state into JSON and throwing over-wire - for small project


My only objection to both frameworks is that reading their source code is a pain in the ass. Reagent is even worse. Tons of single-character variables and a lot of magic without explanation.


I found the re-frame documentation extremely helpful, but I also compared plain reagent's todomvc and om's todomvc, and I found reagent much easier to read and understand. I hadn't heard "Form-n" before, but I find them quite simple as well.


I needed to do some optimization work recently[1], and understanding reagent internals was pretty hard. Also I wanted to write my own render queue. I had to copy and paste pretty big chunk of code and resort to monkey-patching. [1]


@mbertheau: Form-n sounds pretty simple to people who understand lexical closures and get to read Mike’s docs. Not that many people satisfy both conditions, I guess simple_smile


@mbertheau I too remember comparing the todomvc examples from OM and reagent, and finding myself much preferring the reagent version. If I had to start again, right now, I'd be tempted by Elm (before probably still coming back and choosing clojurescript). There's a lot of very clear thinking going on over in Elm. And the language stewardship of Elm is quite a bit, er, better than that provided by Clojure in my opinion, sadly. A really nice trajectory. But back when I had to make my decisions, Elm didn't even have js interop. I just couldn't choose it at the time even though I could see it had promise. One library in cljs which does not get NEARLY enough attention is Hoplon.


That's a fine bit of work


But, like reagent, it isn't one of David's projects and as a result it just doesn't get the same profile. simple_smile There's definitely an advantage to having 1 billion followers in github and twitter simple_smile


So who is this guy David other than om's author?


Yeah I mean why does he have so much influence? What did he do? He's not Rich Hickey simple_smile


David is really bright, is an enchanting speaker (keynote material) and has a lot of mojo.


David has his own emoticon, who can say to have it except for Rich? simple_smile


I've seen talk by David last year about general immutability (with examples in Om), and it really moved my point of view on web apps. Now as I started to develop in clojurescript I can't agree more with what I heard there.


@mikethompson: Appendix A is a great upgrade. Is it worth adding in the danger of adding subscriptions in the outer fn based on input when using form 2 components (e.g.` (defn [x] (let [s (subscribe [:sub-1 x])] (fn [x] [:div @s]))`) or am I the only one that has happened to simple_smile


@colin.yates: this is a document about pure reagent, not re-frame. So I don't think I can mention subscriptions


I get your point, and if I am the only one who has been bitten by that issue then fine, but that seemed a natural place to put the info which might help newbies (who that page seems to target?)


just a thought, no big shakes simple_smile


That page is supposed to be a reagent level tutorial


Will be transfered across into the reagent Wiki in due course


ah OK - that wasn’t clear.


> Tell me if that works for you. @mikethompson: the appendix you added to “Creating Reagent Components” helped tremendously. Thank you.


@mikethompson: you mentioned hoplon - do you have a view on which would be more performant for long chains/deep trees of reactions; re-frame’s subscriptions or hoplon cells?


Actually, all three of those links you posted are really helpful. (And I had already read the non-appendix part of the first linked article several times in the past.)


I suspect I’ve been using Reagent non-optimally.


So, having concluded reading all three of those articles, I’m left with only one question – why doesn’t a change to a ratom cause lifecycle functions to run? It causes the rerender to re-execute, like a change to the props.