Congratulations on your release!
Don't let my skepticism (below) to detract from your accomplishment.
I am deeply skeptical not only about this tool in particular but about these tools (e.g., Dash, Panel, Streamlit &c.) in general. I've seen these tools work well for very simple use-cases, but they seem to require some combination of…
· cooperating requirements (matching exactly what the demos do, so you stay completely within the “regime” these tools support)
· upfront knowledge of all requirements (so that you never fall out of this regime)
· the ability to reject requirements (so that you can keep yourself within the regime, though this means the tool is leading the business, not the business leading the tool)
· the ability to accurately identify the boundaries of the regime from the tool documentation and design
For very simple examples, it's may be possible to stay within these constraints, but even when you manage to successfully use these tools, you do so at high (and, in my view, often unacceptable) risk.
In general, the risk/reward for a tool like this is about being able to learn the tool almost immediately (which must also account for time spent trawling through the documentation or the Github issues or even the `dir(module)` to figure out how to spell that one thing you need.) Basically, if you can create something in 1 day that can last for 180 days before a requirement comes along that forces you to start over from scratch, you may be okay.
You certainly never want to become good at these tools; the more you invest in the tooling, the harder it will be to abandon it when it is no longer appropriate, and the more willing you will be to accept contortions that you will inevitably regret. You certainly never want to spend more than a trivial amount of time building something with these tools, since the risk of needing to rebuild or abandon the technology is simply too high.
(Personally, I simply don't think React is that hard to learn, that hard to teach, or that onerous to use…)
In particular, this tool's API seems particularly risky. e.g., in the example code, there is a section like this:
cond(
State.mode,
element,
cond(
State.flag,
other_element,
),
)
So we're encoding the control flow defining the layout in some sort of object graph (some sort of pseudo-AST)? It's not going to take a lot of this to spiral out of control. Unless you can recognize that this tool is unsuitable for even mildly complex programmatic component layout (which is trivial to do in React,) you're going to hit an impassible brick wall trying to handle what will otherwise be considered a benign business request.
I suspect, however, that this API is still being refined. After all, what if I wanted to trigger on two conditions? There are probably some sophisticated `metaclass` mechanisms wrapping the `State` attributes in some symbolic modelling, but SymPy shows us that this is not trivial to get right, and the Python object model constraints you in unpredictable ways. Without looking at the code, I suspect you cannot `cond(State.mode1 | State.mode2, element)` and probably have to create some sort of `State.mode1_or_mode2` subordinate data, which spirals out of control pretty quickly. And what if you want to do `cond(State.mode | mutable_global_mode)`? And so forth and so on.
There are so many structures and modalities for control flow and data flow (trivially expressible in React) that will become clumsier and clumsier to express in with this modelling, and unless you can anticipate that they won't arise, reject the business requirements that mandate them, or (with no regret) throw everything away and start over from scratch, you're going to have a good experience.