Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decoupling components #160

Closed
vjpr opened this issue Jun 21, 2015 · 3 comments
Closed

Decoupling components #160

vjpr opened this issue Jun 21, 2015 · 3 comments

Comments

@vjpr
Copy link

vjpr commented Jun 21, 2015

A lot of the examples and discussion in general do not seem to place much importance on being able to extract components into npm modules for re-use.

How does the community feel about this as a design consideration?

Say I have a component with a couple of nested components, I'd like the ability to be able to extract this into a component and publish it on npm. For this to be easy, everything needs to be passed in as props at the top. @gaearon started a good thread on SO about how to deal with nesting.

It would be great if the docs could provide some examples for these nested use cases, and would suggest a best practice.

The problem I ran into with feeding everything down from the top is performance, with a small change to a deeply nested component requiring a complete re-render.

It would be ideal if everything supported props, and then I could bind certain components state when its neccessary for performance reasons. Maybe a way to pass store bindings as props?

@gaearon
Copy link
Contributor

gaearon commented Jun 21, 2015

Currently Redux lets you pass select prop to Connector to choose the slice of the global state you're interested in. It's totally possible to compose those select functions so, to avoid expensive re-renders, instead of passing the data, you can pass those functions down. Child components may define their own select taking this.props.selectRoot (or whatever parent calls it) into account, and can even pass those down too. Because the functions are not likely to change (in best case they're outside component, in worst case bound to some particular props) there's no cost to passing them down. Now, components closer to the leaf ones (where re-rendering is relatively cheap) are able to finally use Connector with whatever select function they want (which as I said above may be composed through several levels of components). The nice thing is, because Redux assumes data is always immutable (even if you use plain JS objects), it is able to shallowly compare the results of select function calls and determine whether a deep component needs to re-render.

I would definitely love to see this explained in examples and new docs. Cc #140.

@gaearon
Copy link
Contributor

gaearon commented Jun 21, 2015

Related: #47

@gaearon
Copy link
Contributor

gaearon commented Jul 7, 2015

Closing, let me know if my comment wasn't clear enough.
Also check out https://github.com/faassen/reselect for efficient nested selectors.

@gaearon gaearon closed this as completed Jul 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants