We gave up on local state, we now use it only for things like popup on/off.
We are using atoms and subscription to the atoms. It’s not really global (it’s in a var in a namespace) but you don’t have to think about passing dispatch functions around.
In practice it ends up being a stateful component that subscribed to state, and just renders a stateless one.
After a few rounds of polish I will document reseda a bit more and make a release of sorts.
That is another thing I could've done, to use clojurescript's own state management mechanism so I have access to easy debugging through the REPL. Even though I can manually extract react hook values through the react dev tools, it's not very convenient to do so repeatedly. Too much clicking.
interesting. we’ve done the opposite
we started with a large re-frame app, and are adopting helix and putting most things in local state
the only thing that doesn’t go in local state is routing (we already had a routing solution) and data from the backend
and how do you inspect local state during development?
are you using atoms?
using React DevTools to find the component and then logging them to the console for inspection of the CLJS data
or placing console.log’s inside the body of the component
or tap>
in shadow-cljs especially
@dpassen1 how do I use tap> to investigate the contents of a react hook? I have never used tap> before, I am not even sure what it is, people talk about it like it's common wisdom
Just any place where console.log works
shadow will send that to its inspect tab
@lilactown that's what I do, and (js-debugger)
but it's extremely cumbersome and time consuming, I would not like to continue to debug like this.
@dpassen1 but that's the thing, console log is not adequate for this, I need to see live data from clojures without having to manually decorate it with calls like (prn)
What @lilactown says is very useful here because there is a top-down direction of selecting which components' which hook to inspect at any time when I have a breakpoint or anything. I am not aware that I can introduce new console.log calls when execution is suspended
it's just that the manual labor of selecting the component and clicking around to open the tree and inspect the values is like the least favorite way of any activity I could imagine doing at a computer 🙂
hehe
at some point I’ll come up with a design I like for looking up state at the REPL
ctrl-c ctrl-e 😛