Clojurians Log v2

Sorry about that - didn’t mean to be rude or insinuate anything. Arguing on slack isn’t the easiest form of getting my point across.

Something is brewing over at react: https://github.com/facebook/react/pull/18774

I’m honestly tired of trying to ride this wave. I was just reading the docs of om.next -> such a nice paradigm, created almost 5 years ago.

Interesting... I'm... Hmm. I don't think this stuff matters does it? I can't convince myself to care all that much about the scheduler. It's nice that input events get handled first, but beyond that I'm not sure it matters :thinking_face:

it does and it doesn't. From cljs perspective, where you have several options to choose from libraries that allow all kinds of optimizations on how to handle state (to components), it doesn't much really, the good thing is the reconciler that updates the dom. OTOH, from javascript perspective, it's impossible to guarantee that you calling this.setState({some: 'literal'}) won't block the UI unless you have something like their async renderer that basically cuts long running renders into chunks. It's an overkill for antyhing that one person can write, but facebook has between 30k-70k components internally that they have to maintain...

Unless they got rid of them in the past couple of months, I don't have a live counter : D

but even from cljs perspective I think it's a nice to have optimization when you do have to write a lot of components. Or, I also feel it's helpful, when you are using messages internally on the frontend and you don't have to care about calling ReactDOM.render() 60 times a second.

It's fine, it's how it should work ; )

I think I had a kind of personal clarity moment, for the thing I want to pursue - a way to bind one (or more) external store to native React in a suspense-friendly way. The store should be abstracted behind a protocol and could be as simple as a map inside an atom, or could be anything else.

This way, mutating the store can be a separate concern that’s much more targeted to the complexity of the application you’re building. For simple stuff, swapping an atom is ok. For more complex, dispatching actions or whatever. Same for handling async stuff, normalized caches etc.

And, I want to pursue a Clojure-minded approach, with REPL interactions, build your own tools etc.

Hopefully we can approach the domain by having libraries that compose well and also integrate well with React. Ideally you’d be able to build re-frame on top of this adapter (for example).