Architecting UIs for Change

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

Re: Architecting UIs for Change

#5

Post by uxcolumbo » Sat, Mar 23, 2019, 9:19 AM UTC

anonytrary wrote: post #3

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

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

Edit: if you find it valuable you can also buy a digital copy

Re: Architecting UIs for Change

#6

Post by lioeters » Sat, Mar 23, 2019, 11:29 AM UTC

While I don'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 "run an entire functional application without any visual components having been built whatsoever".

This decoupling of state (and its reducers/actions) from view is a powerful architecutral pattern that I learned from Redux, and I've built every React application (or component) following it. It'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/rebuild/extend the view as its own separate layer of concern. Looking back, it's hard to believe I was able to keep things organized any other way.

Re: Architecting UIs for Change

#7

Post by _0afm » Sat, Mar 23, 2019, 12:02 PM UTC

lioeters wrote: post #6

While I don'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 "run an entire functional application without any visual components having been built whatsoever". This decoupling of state (and its reducers/actions) from view is a powerful architecutral pattern that I learned from Redux, and I've built every React application (…

Hi, I have exactly the same conclusion as you - you can check my demo todo app - where the UI is an extension to the app. I'm having React and Mustache renders to demonstrate how the view is totally decoupled from the app logic. It have SSR, both for React and Mustache, Service worker for offline usage. Redux for state management. I'm using typescript.

https://drmzn-todo-app.herokuapp.com/

https://github.com/max0xff/drmzn-todo-app

https://github.com/max0xff/drmzn-todo-app/blob/master/About....

I would love to hear your feedback :)

Re: Architecting UIs for Change

#8

Post by dovel » Sat, Mar 23, 2019, 12:40 PM UTC

lioeters wrote: post #6

While I don'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 "run an entire functional application without any visual components having been built whatsoever". This decoupling of state (and its reducers/actions) from view is a powerful architecutral pattern that I learned from Redux, and I've built every React application (…

Do you store all UI state in redux as well as all 'resource state'? Phrased as an example... If you store a JSON object that can be edited in your store do you also store a Boolean value for whether the dialog is open that can be used for editing that JSON object?

Re: Architecting UIs for Change

#9

Post by sktrdie » Sat, Mar 23, 2019, 12:50 PM UTC

I like this approach. He's essentially using selectors for most of the app logic, which are cached and are what the view components use to derive data. They're cool because they always give you a "fresh look" at what's in state. I find it interesting in his implementation that selectors can also dispatch other actions.

If the author is reading: have you ever read about Behavioral Programming (BP) principles?

I have written a bit about it here:

- https://lmatteis.github.io/react-behavioral/

- https://medium.freecodecamp.org/an-intro-to-behavioral-progr...

And also have given a talk about how UIs can better align with requirements: https://vimeo.com/298554103

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: Architecting UIs for Change

#10

Post by lioeters » Sat, Mar 23, 2019, 1:07 PM UTC

dovel wrote: post #8

lioeters wrote: post #6

While I don'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 "run an entire functional application without any visual components having been built whatsoever". This decoupling of state (and its reducers/actions) from view is a powerful architecutral pattern that I learned from Redux, and I've built every React application (…

Do you store all UI state in redux as well as all 'resource state'? Phrased as an example... If you store a JSON object that can be edited in your store do you also store a Boolean value for whether the dialog is open that can be used for editing that JSON object?

Hmm, typically, I do store "UI state" (or parts of it) in the top app state if that UI state is shared among pages/routes. In your example, if I want that dialog state to be "persistent" - say, the user goes to another route then comes back, if the dialog state should be kept. Otherwise, I store them in the route component's state, which gets created anew every time.

But your question makes me think, if I store any UI state in the app state, have I really decoupled state and view? I'd say yes - since I'd be able to build and test UI state and actions, independent from the view.