One little rule of thumb or idea about individual widgets is that quite often, you will want the inputs to a widget to be Dynamics that tell you the ground truth about what the state of the widget ought to be, and the outputs from the widget to be Events that tell you how the user interacted with it. This leaves the decisions about how to maintain the state of the widget up to some higher level thing -- you can immediately cap that off by introducing a foldDyn or holdDyn and using recursion to create a self-contained widget that maintains its own state (but might hide some of it from the outside), or you can combine together a bunch of such things and make all the decisions about how the state ought to change farther up.
Deciding where the holds ought to go requires insight into how your application works. If you leave them all for the top level of the application, you end up with something kind of like Elm's prescribed architecture, which usually means you end up with this top level part of your application needing to "know" too much about every little widget. If you tie things off too early, you make it a little harder for separate parts of the application to interact with each other. Generally, you want the holds to be at some point above all the things their state will affect, and no higher.
and on the other hand
Some general pointers are to break up your events and behaviors as finely grained as possible. It is often good structure to pass in Events and Behaviors to components which return Dynamics or, preferably, Behaviors. It is often a warning sign when you're passing Dynamics in or Events out.
Sorry if I quoted without enough context: former is talking about widgets while latter is about large scale apps, thus not exactly about the same thing.
Anyhow, while thinking of the current text at
http://docs.reflex-frp.org/en/latest/overview.html#architecture-of-a-reflex-dom-application,
in addition to it, it might could compose somehow both of the above recommendations. There could be notes about potential caveats of the chosen approach as well as the benefits and other implications it entails. And maybe even some picture / schematic example code how to manage states and where etc. Or a separate section?
Current text at http://docs.reflex-frp.org/en/latest/overview.html#architecture-of-a-reflex-dom-application refers to the question on how to structure a reflex application. There is also a question about the use of giant dynamic and on how well reflex apps scale.
On one hand
and on the other hand
Sorry if I quoted without enough context: former is talking about widgets while latter is about large scale apps, thus not exactly about the same thing.
Anyhow, while thinking of the current text at http://docs.reflex-frp.org/en/latest/overview.html#architecture-of-a-reflex-dom-application, in addition to it, it might could compose somehow both of the above recommendations. There could be notes about potential caveats of the chosen approach as well as the benefits and other implications it entails. And maybe even some picture / schematic example code how to manage states and where etc. Or a separate section?