Architecting UIs for Change

While I don&#x27;t use Redux anymore, one point in the article really resonated with me: having a single source of truth for the entire app state enables you to &quot;run an entire functional application without any visual components having been built whatsoever&quot;.<p>This decoupling of state (and its reducers&#x2F;actions) from view is a powerful architecutral pattern that I learned from Redux, and I&#x27;ve built every React application (or component) following it. It&#x27;s separation of concerns at its best, where the heart of the app is about designing data structures and interfaces (as in API), with reusable, composable, and unit-testable states and actions. The UI then becomes just another consumer of the API, so one can develop&#x2F;rebuild&#x2F;extend the view as its own separate layer of concern. Looking back, it&#x27;s hard to believe I was able to keep things organized any other way.

I like this approach. He&#x27;s essentially using selectors for most of the app logic, which are cached and are what the view components use to derive data. They&#x27;re cool because they always give you a &quot;fresh look&quot; at what&#x27;s in state. I find it interesting in his implementation that selectors can also dispatch other actions.<p>If the author is reading: have you ever read about Behavioral Programming (BP) principles?<p>I have written a bit about it here:<p>- <a href="https:&#x2F;&#x2F;lmatteis.github.io&#x2F;react-behavioral&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lmatteis.github.io&#x2F;react-behavioral&#x2F;</a><p>- <a href="https:&#x2F;&#x2F;medium.freecodecamp.org&#x2F;an-intro-to-behavioral-programming-with-react-request-wait-and-block-ad876e2d235e" rel="nofollow">https:&#x2F;&#x2F;medium.freecodecamp.org&#x2F;an-intro-to-behavioral-progr...</a><p>And also have given a talk about how UIs can better align with requirements: <a href="https:&#x2F;&#x2F;vimeo.com&#x2F;298554103" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;298554103</a><p>BP is still driven by trying to make change easier to implement in a large codebase, so I think there are some high-level similarities with your approach.

re-frame (<a href="https:&#x2F;&#x2F;github.com&#x2F;Day8&#x2F;re-frame" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Day8&#x2F;re-frame</a>) essentially implements the ideas and patterns presented in the article&#x2F;post. Of course you would need to learn ClojureScript to use it, but that might be worth it.<p>I really like the &quot;selector&quot; pattern. Your app state should not have to reflect your UI component tree. Rather you use selectors to subscribe to some part(s) of your application state and derive any necessary values in the subscription&#x2F;selector function.<p>Representing your app state as a single source of truth and expressing all changes to state as effect handling functions means you can now easily test your front-end app without involving a dom at all! It is state transitions that are interesting.<p>Of course there are other options like Redux and Vuex for React and Vue respectively as well as the elm language if you want to go all in on static types and compile time error checking.

&quot;If you don&#x27;t actively fight for simplicity in software, complexity will win&quot;

I think there actually is an issue with our data models. REST apis have moved a lot of the complexity of data fetching on the client apps since it is basically a 1 to 1 mapping of the database schemas. Making connections between the different data types becomes a frontend concern which is not ideal since frontend has to deal with partial data and full network latency &#x2F; failures.<p>Thinking in graphs and query languages like GraphQL makes building for change a lot easier. Your api now defines all the possible data types and their associations (think nodes and edges). This completely eliminates the need to write data management code as a graphql client library can take care of fetching, normalizing and providing the data to components since it knows about the data schema.<p>Queries can also be composed from fragments which goes very well with the React component model. This allow each component to define the data it needs and then all those fragments can be composed to generate a query. This query will only fetch the exact data it needs for what is displayed wherever the data comes from.<p>It does move back a bit of the complexity to the backend (defining schema, fetching connections between the different data types) but this is a lot easier to implement since you have full access to all resources. It is also easier to iterate on the implementations since code shipped to client apps can be hard to update when considering mobile apps.

We started using ~this selector pattern for timelyapp.com almost two years ago, and have found it tremendously helpful.<p>Anytime we’re reading data from Redux, it’s via a selector (usually a composition of multiple selectors).<p>For data fetching, we use a slightly different approach, but same principle: An xhrCacheBuster string that, when changed, fires a thunk action. Query params&#x2F;payload is determined via a selector in the thunk.<p>We use similar patterns to “sign” expensive-to-render things, then compare the renderCacheBuster string in shouldComponentUpdate. Same with virtualized lists (named virtualizationCacheBuster)

From my experience, a successful UI doesn&#x27;t need to map 1-1 to your domain&#x2F;database models. The principle is &quot;less is more&quot;, that means, deliver only enough functionalities for users to complete their process. So, &quot;less is more&quot; just means &quot;less distraction, more focus&quot;.

What would be the difference (if any) from the selector concept presented in the article vs the reducer pattern in redux?

TLDR: State is hard, use createSelector from Redux and read my book which explains it in depth.