[logicchains]

I encourage anyone who likes React and doesn't mind lisp to check out Reagent, an awesome Clojurescript library built atop React that manages to completely hide its complexity. It's by far the most fun I've ever had with web development; the way I feel now is like how I imagine people who've had religious epiphanies must feel when trying to show potential converts the proverbial light of god.

https://reagent-project.github.io/

[findjashua]

could you elaborate what specific complexities it abstracts away?

[logicchains]

It essentially combines all of React into a single component, the Reagent atom. It's used exactly like a normal Clojure atom, but whenever it's updated, Reagent will automatically update all Reagent components that depend on it. I find this quite elegant, as it allows one to write pretty much any reactive ui using only three functions: deref, update and render-component. Reagent atoms can even be passed between Clojurescript async threads, and will still work as expected, which completely eliminates the need for any kind of callback hell.

So what it eliminates is the need to learn React. Anyone who understands how Clojure atoms work and how to use Hiccup-style HTML templating will be able to use Reagent with almost zero learning curve.

[findjashua]

So Reagent is like React + Baobab (https://github.com/Yomguithereal/baobab)? Since Clojurescript has to compile to Javascript anyway, I can't think of a reason why Javascript can't have a counterpart to Reagent.

I'm not familiar with Clojure, but it seems like atom is the data tree that holds the state of the entire application. If so, could you give an example use case of when you'd pass the data tree between threads, and what advantages it has over promises or es7 async/await.

Just to be sure, I'm not questioning the validity of your claims, I'm genuinely curious about how things work in reagent.

[logicchains]

There doesn't have to be a single atom holding the whole application, that's just an approach some people take.

An example of passing data between threads: imagine a forum that allowed indefinitely nested comments. It also loads comments lazily; one must click to load a comment's child comments, in which case they'll be loaded from the backend. However, if the child comments are minimised again, then expanded again, another backend request won't be made, as the data is already loaded.

I approached this by having a separate 'thread' running that just listened for messages (maps) on a channel. If it was a :get-children message, this thread would check the local cache for the parent comment's ID, and if it found it then it'd add the data to the atom provided in the request, otherwise it would fetch the data, add it to the cache, and then add it to the provided atom.

The comment component would then take a copy of that channel, which it'd pass to its children, and to get comment children data it'd just pass a :get-children message into the channel with an empty atom for the other thread to fill. If a button was clicked that changed a comment somehow, then it could send a :update message through the channel with the parent id, and the other thread would re-fetch the relevant data from the backend.

Of course, there's nothing here that couldn't be done with promises/async. I just personally find Go/Erlang style message passing between threads to be simpler and easier to reason about than async/await, and I believe Reagant/Clojurescript would appeal to others who feel similarly.

[arms]

I'm a big fan of Clojure and React, but haven't used Clojurescript or Reagent. I find React pretty easy to grok so I'd be interested in how you think Reagent makes it easier to use.

[logicchains]

Reagent means you don't have to grok Reagent at all. If you know how Clojure atoms work, how to use Hiccup-style templates, and understand that all templates ('components') that dereference a Reagent atom will be automatically updated when the atom is, then you know how to use Reagent.

[KingMob]

I think you meant "grok React". But yes, Reagent is super-nice. I'm surprised much of the community has gone for Om, since Reagent strikes me as much cleaner 98% of the time. Om maps closely to React, when most of the time it doesn't have to.