Skip to content
This repository has been archived by the owner on Apr 5, 2022. It is now read-only.

Components should not rely on Redux #199

Open
aztecrex opened this issue Jun 5, 2019 · 2 comments
Open

Components should not rely on Redux #199

aztecrex opened this issue Jun 5, 2019 · 2 comments

Comments

@aztecrex
Copy link

aztecrex commented Jun 5, 2019

Components with visual behaviors should manage their own state and not rely on Redux.

The side nav requires redux for its visual behavior. To use it, the application needs to configure Redux, breaking encapsulation. If the application happens to use Redux, the configuration presumes a particular way of merging state machines, further breaking encapsulation.

@fiddlerwoaroof
Copy link
Contributor

I generally design components for packages/visual-stack to not do any state management, because I don't want to have to think about inconsistency between the state the component's user expects and the internal state of the component.

Perhaps we could create a second package like visual-stack-redux that provides versions of visual-stack components that handle this sort of state using local state?

@aztecrex
Copy link
Author

aztecrex commented Jun 6, 2019

100% disagree. If a component has a visual behavior, it should be encapsulated. If that requires the component to have mutable state, then the responsibility for managing it is with the component. This is the essence of encapsulation. Forcing a component user to add additional dependencies and code just to get a component to work is a cognitive load that simply doesn't scale.

A component user should be able to drop the component in place and not have to care about how it works. If a user is going try and impose their own state changes on that component, that user is breaking encapsulation so buyer beware. They should probably wrap the component instead. If a component allows a user to change its state, it must expose that through a well-documented, cohesive interface, not allow a user to directly modify the state based on inappropriate knowledge of the internals.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants