-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Remove shouldComponentUpdate #625
Conversation
Let's see what happens...
Whoa. That is some seriously advanced hacker-fu there. bows down So just to confirm my own understanding: now that we're doing everything with layers of memoized selectors, |
@markerikson Yeah. I think #507 (comment) explains why sCU isn't a requirement anymore. |
That would be a breaking change, right? Many apps are likely relying on this behavior—if not for functionality then for performance. I agree it might be better not to impose purity on everyone, but people are already treating |
Yeah, it would probably be worth a major bump. I guess what I'm trying to nail down is: does the memoized internals approach give the effect of |
I can’t answer this because I don’t know how the new implementation works. |
Yeah, that was really meant for @jimbolla . Looking at that deleted couple lines, I'm pretty sure Although re-reading Jim's comment from the other thread, maybe I'm misunderstanding this? |
This would certainly be a breaking change. sCU is no longer needed for changes coming from store, but still affects changes coming from props. People, including myself, rely on I'm feeling like this should wait until "React 16 - Now With FIber™" lands so that we can see how it affects performance. It's possible that R16 could change the way we get maximum performance and we end up wanting to keep sCU. |
I would add that after React 16 (e.g. maybe in 17) we'll likely make Fiber async by default (you can flip the switch here if you build it yourself). As a result, |
Ah... as far as I know, we don't use |
Heads up: React 16 might not need this but it is possible React will rely more on sCU in the future in order to better reuse work in async scenarios. The details are still very fuzzy (we just started looking into trying to use async rendering at FB) but I wouldn’t hurry with this change in case we need to backtrack later. The context API is another beast because that’ll need a redesign anyway (likely in 17). |
OK, finally updated this damn thing. I removed some tests related to f7dc41d, which was some of the original attempts at optimizations. This raises a slightly modified question: Should we be responsible for handling sCU? The whole point was to be automatically aware of state changes that don't require updates and stop them with sCU. The unfortunate side effect was this required us to handle ownProps updates as well and we ended up applying our update-blocking logic to those props. But I think this may be a mistake. We're making assumptions about how we want connected components to update, while lacking actual knowledge of the business meaning of ownProps. I think implementing sCU should be left up to the user. Very commonly, they end up getting lazy and not ever doing it (I know I'm guilty of this!), even in non- So, this may involve more than just fixing some code. We would have to be sure to educate people about this. And it may be a little painful, but I think it's worthwhile to get people thinking about writing their own sCU's. |
I am very concerned about changing something like this, especially after we already have a report about 5.x significantly regressing on performance. #686 |
Basically, the way I think about it that Redux plainly wouldn't work on larger apps unless you aggressively optimize sCU. It makes sense to me to do this by default, as this is a more opinionated way to use React. Just like Om. |
Does this really solve the problem? or simply shifts the responsibility to the users, like me :) |
Also, I don’t think this will fix context bugs in practice. IMO you need to use sCU in a Redux app (otherwise single store is impractical), and as soon as you implement your first sCU, context is broken again. |
So, now that |
@wtgtybhertgeghgtwtg : maybe. Dan and Andrew have both said that the async React behavior they're currently prototyping and experimenting with will likely require changes in how other libs interact with React. Andrew has also said that at some point he'd like to have a discussion with the various state management lib maintainers on this topic. React 16.0 deliberately maintains as much backwards compatibility with 15.x as possible. Later iterations of 16 may start changing that. So, it's still too early to know what sorts of changes React itself is going to have and how those will affect the ecosystem, and therefore too early to know what's going to need to change with React-Redux. |
👍 Let's hold off on any big changes until next summer. I think a lot will be clearer by then. |
Will the new context API (facebook/react#11818) mean that this change will no longer be neccessary? |
@tyscorp Only for libraries blocked by |
Closing this out in favor of moving to the new context API. |
Fixes #507 and like every context subscription-related bug ever.
This is just a spike of me editing on the web interface (not on a machine with Node installed...). Travis builds will fail, things will break, no one will be happy. But it gets the ball rolling on removing it, so it's a first step.