How UI-driven state increases accidental complexity

Re:How UI-driven state increases accidental complexity by bernawil on Wednesday March 25, 2020 @03:44PM (#22687826)

  In contrast, it doesn't happen with a denormalized, UI-agnostic state:

Isn't it the other way around? the UI-agnostic state IS the normalized version; the UI-aware state ready to be consumed is the denormalized one.

The choice is pretty simple to me: keep the State normalized, de-normalize it in selectors for consumption in the UI. Those selectors will look pretty much the same as the reducers you'd be writing anyway.

[ Parent | on HN ]

Re:How UI-driven state increases accidental complexity by naasking on Thursday March 26, 2020 @11:36AM (#22694571)

Came just to post this. The state he's described is definitely normalized, and the UI-specific one is denormalized.

And I think your advice is exactly right: project your normalized state into a view that's useful for consumption by other components. Basically, the same pattern we've been applying to relational databases for decades.

[ Parent | on HN ]