Users don't understand models

Our job as user interface programmers is to get the right information to the user at the right time. How do we do this? Conventional wisdom revolves around taking some data that we got from the API and then rendering it as HTML. Apart from semantic markup and some styles, nothing much has changed with the data since it arrived from the API. We're saying here's the data we have, let's make it look nice for the user. Here's an illustration of this idea:

There's no data transformation taking place here, which is fine, so long as the user is getting what they need. The problem this picture paints is that the data model of the API has taken the UI feature development hostage. We must heed everything that's sent down to us from the backend. The reason this is a problem is because we're limited in what we can actually do for the user. Something we can do is have our own models enhance the data that's sent back from the API. This means that if we're working on a feature that would require information that isn't exactly as the API intended it, we can fabricate it as a frontend model, as shown here:

This gets us slightly closer to our goal in the sense that we can create a model of the feature we're trying to implement and put it in front of the user. So while the API might not deliver exactly what we want to display on the screen, we can use our transformation functions to generate a model of the information we need.

During the skeleton architecture phase of our design process, we should think about stores independent of API's as much as possible. Not completely independently; we don't want to go way out into left field, jeopardizing the product. But the idea of producing a Flux skeleton architecture is to ensure that we're producing the right information, first and foremost. If there's no way the API can support what we're trying to do, then we can take the necessary steps, before spending a lot of time implementing full-fledged features.

Stores map to what the user sees

State isn't the only thing that's encapsulated by the stores found in our Flux architecture. There's also the data transformations that map old state to new state. We should spend more time thinking about what the user needs to see and less time thinking about the API data, which means that the store transformation functions are essential.

We need to embrace data transformations in Flux stores, because they're the ultimate determinant of how things change in front of the user's eyes. Without these transformations, the user would only be able to view static information. Of course, we could aim to design an architecture that only uses the data that's passed into the system "as-is", without transforming it. This never works out as we intend, for the simple reason that we're going to uncover dependencies with other UI components.

What should our early goals be with stores and how we transform their state? Well, the skeleton architecture is all about experimentation, and if we start writing transformation functionality upfront, we're likely to discover dependencies sooner. Dependencies aren't necessarily a bad thing, except when we find a lot of them late in the project, well after we've completed the skeleton architecture phase. Of course, new features are going to add new dependencies. If we can use state transformations early on to identify potential dependencies, then we can avoid future headaches.

What do we have to work with?

The last thing we'll need to consider before we roll up our sleeves and start implementing this skeleton Flux architecture is what's already in place. For example, does this application already have an established API and we're re-architecting the frontend? Do we need to retain the user experience of an existing UI? Is the project completely greenfield with no API or user experience input?

The following diagram illustrates how these external factors influence the way we treat the implementation of our skeleton architecture:

There's nothing wrong with having these two factors shape our Flux architecture. In the case of existing APIs, we'll have a starting point from which we can start writing our state transformation functions, to get the user the information that they need. In the case of keeping an existing user experience, we already know what the shape of our target information looks like, and we can work the transformation functions from a different angle.

When the Flux architecture is completely greenfield, we can let it inform both the user experience and the APIs that need to be implemented. It's highly unlikely that any of the scenarios in which we find ourselves building a skeleton architecture will be cut-and-dried. These are just the starting points that we may find ourselves in. Having said that, it's time to start implementing some skeleton stores.