DEV Community

Discussion on: What happened to Components being just a visual thing?

Collapse
 
redbar0n profile image
Magne • Edited

I agree. Thank you for very well reasoned thoughts and thorough backing. As always.

I especially agree with:

React components to become predominantly Visual / Presentation / Dumb components, React's role needs to be constrained to managing the UI and therefore "React state" should only be "UI state".

It's interesting to note that Kent C. Dodds and the community currently separates between two forms of state: UI state and Server Cache.

Whereas where it's currently going is that the Server Cache is not just a cache, but also includes Offline state. The ideal model seems something like AWS Amplify DataStore, where the client app has its own state that it will automatically sync with the server. All the while the developer has a nice and simple API to deal with, and not directly concerned about caching, normalization etc. The only problem is Amplify DataStore's bloated bundle size due to its ties to AWS (Cognito auth esp.). So even though open sourced in principle, it's not really universally useful. It has to do with the server sync component and conflict detection needing a server-side counterpart.

This is attempted being solved by Offix DataStore (previously Offix Client, built on top of Apollo Client). Together with the counterpart Graphback, developed by the same people.

This makes the client effectively a part of a distributed system. With all the complexities that entails...

Markbåge seems to think the distinction / architecture doesn't matter:

I think this also plays into the question of "app" vs "component"-based mindsets. Is React your actual "app"? Or is it "just" the UI layer, with the real app being the logic and data kept outside the component tree? Both valid viewpoints. - Sebastian Markbåge, at twitter.com/acemarke/status/114900...

Whereas we think any such perspective will taint the entire client side app, for better and worse. Plus impedance mismatch of people thinking differently and trying to serve the same ecosystem and use each other's libraries.

As you said:

Application state and the effects that manipulate it need to be at the centre of the client-side application - not the UI and much less the framework that implements the UI.

The funny thing is, isn't this where we started: with MVC on the client? Presumably with dumb views. The problem was two-way data-binding, which React brought the Flux architecture to solve. But maybe it should be updated, so that Flux decouples the state from the View layer?

Like Surma did with react-redux-comlink in that presentation you shared. The funny thing is that Redux kinda enforces this separation of concerns between state and rendering But it has been shown to be way too complex for most people and use cases to be worth it in general.. Maybe there is a simpler way?