All the examples of DDAU that I see tend to be for relatively simple models and arrangements of controls, the kind that occur in CRUD based apps. (I’ve always preferred the gentler acronym FLUID - Fetch, List, Update, Insert, Delete). I need to make sure that I am advising my team correctly. I’m hoping somebody can help me out.
We make apps that let people play with the behavior of various kinds of devices and circuits. The GUI lets the user set the values of a whole lot of electrical data. The user tweaks all the knobs and sliders and pokes the buttons, and the schematics and graphs and such change dynamically as they play, thus helping the user develop engineering intuition about the circuit. All navigation is among tabs of what is modeled as a single page and all the engineering math is done on the fly in the browser. The only ReST calls to a back end are for utility tasks, like saving or loading a JSON dump of the settings, zipping up and downloading information, or providing feedback.
Item #1 - Use of components:
We are composing our applications using components for a deep hierarchy of panels. We have components for the major GUI organization, with components within that for the various sections and components within that for smaller panels of individual controls or even wrapping individual controls themselves. We are sometimes four or five layers deep in components.
Q: This is pretty normal, right? Or should we be going shallower with the whole organizational structure laid flat close to the top and reserving components for the lowest level panels that actually have complex behavior that generate actions?
Item #2 - Composability of DDAU:
A single deeply-nested model describes everything the user can affect and all the visualizations to display. Since the GUI is structured around related concerns, the structure of the model and the structure of the GUI tend to be closely related, with different hunks of the model passed down to the components for different parts of the GUI.
If we take the approach by which DDAU is conventionally presented, we quickly get to the point where every data change created by every control of every one of our components get funneled back through closure-action component attributes to actions on the sole route (or perhaps the controller) because it is the only thing that is allowed to touch the model. That either makes for one really fat spot in the application or really generic actions like updateModel(‘a.b.c’, value) !
Q: Is that expected for a well-designed application? Since some parts of the GUI are only concerned with some parts of the model, is there a composable way that DDAU can be safely applied? If final actions that affect portions of the model occur in the components for the panels governing those portions, is that still “Actions Up” ? Are there guidelines for what makes that safe or unsafe?