It might also help (while you troubleshoot) to use …(pr-str @state) … instead of just @state inside the button text, to produce a readable form of it, e.g., “” instead of nothingness. Furthermore, there is no dishonor in (print (pr-str @state)) as it helps you know not only what’s in the variable but also how often, and when, the function body runs.
Good to know about pr-str, I hadn’t come across that yet. I’m well versed in printf debugging. I haven’t used an actual debugger in over a decade. Working with multi-threaded and multi-process programs, debuggers just don’t work as well. Trace logs are much easier to use.
I keep hearing how awesome an experience the REPL is, so I’m looking forward to experiencing said awesomeness.
It struck me as strange how the reagent code was structured since it seems like trying to force OOP onto an FP language. It seems to me the FP way would be to have the state passed in so that, for example, the description of a button could be used to initialize different types of buttons. I’m thinking I’ll probably end up doing it that way instead of the nested let approach.
Both approaches – components which keep their own state vs. take the state as an argument, both have their pros and cons… Here are some videos I found helpful in this regard (they use re-frame for state management, but it’s pretty similar to using an atom):