Fork me on GitHub
Noah Bogart00:05:42

are there tutorials about how to do the normal "this.state.props" idiom in reagent? is everything handled by global or let-bound r/atoms?


I don’t recall, but personally I tend to pass them as arguments to the component function and if necessary bind that to the r/atom.


@nbtheduke what are you interested in doing?

Noah Bogart19:05:59

:component-did-update fn needs to know what the change is. i can't quite do this with component-will-update, because i need to pass information between the two, so i instead set a flag on an atom and check the flag

Noah Bogart19:05:21

i have a chat message window, and i want it to scroll only when i'm scrolled to the bottom

Noah Bogart19:05:40

the code is not written super cleanly, lol, so this is more challenging than i'dhoped


The general solution for state management with Reagent would be atoms, yes, so you should not need to reach for something like this.state.props. For example, I have reimplemented non-trivial React components like Drag and Drop, Resize-able containers and Material Ripple Effects and used atoms for these.


But its difficult to say without seeing code.

Noah Bogart22:05:33

My issue I think is that dealing with defonce'd atoms feels like a code smell, given that globals are generally a bad idea


@nbtheduke sounds like there’s a few things going on: 1. You shouldn’t need to use component-did-update, etc. in general with reagent, unless you really know what you’re doing. I’d have to know more about your problem. 2. I’m not sure what you mean by "this.state.props" idiom. generally, tracking props in state is an anti-pattern in React 3. your aversion to globals is warranted, which is why I try and maintain most of my state in let-bound atoms. This becomes difficult as your application grows, though.


there are some design choices in reagent (and some realities when paired with the way CLJS does hot-loading) which makes tracking state in globals much more attractive and tenable. I think in the 80% case, this is fine