Sanity check: Guidelines for DDAU and component nesting?

1

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) :slight_smile: !

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?

Thanks…

1 Like
2

For Item #1, I’d say that’s pretty normal as long as the concerns for each component are clearly defined. The only problem is of course you’d have to bubble those actions all the way up and could get confusing if your mind isn’t totally focused on how the components are organized.

For Item #2, what you’re describing I believe is generally acceptable best practice. In earlier versions of Ember, I’ve cheated in creating a “container” component where when nesting is too deep, I let the container component deal with the model updates for only that section of the nested components. But I think that’s a frown upon practice and I wouldn’t recommend it in today’s “reactive style” programming practices.

3

I know it’s not really optimal to link to content behind a paywall, however my colleague sent me this recently and I think it’s the very best explanation of DDAU and when to use it and when not to that I’ve seen so far:

The first video you can watch for free, however it’s the second video you really need to see.

The tl;dr is basically that when you are building reusable components, you really need to adhere to DDAU. But when you’re building what he calls “smart components” that are specific to a single use case in your app, DDAU adds unnecessary burden without providing much value. So if you’re building ember addons, you probably are building components that are all DDAU. If you’re building a {{blog-post-form}} component in an app, it is going to be smarter because it can make some assumptions about how you’re using it (ie, to create or edit a blog post).

2 Likes
4

Many thanks. So often, we end up with design directives when what we need are design tradeoffs and guidelines.Your comments and the video series provided exactly what I needed, augmenting what I got from the fine folks out on Slack. It solved a problem I’ve been struggling to get a handle on for months. Since the excellent video is living behind a paywall, I’ll make do and present this to my team, using examples from our own code. It should be a good time.

1 Like