Guard against SSR leaks in <Router> constructor
See original GitHub issueWe should have a guard around the history.listen call in the <Router> constructor to be sure we are in a persistent environment first (see https://github.com/ReactTraining/react-router/issues/6060#issuecomment-424575126).
The ideal place for this listener would be componentDidMount, but we can’t move it there and preserve backwards compatibility with existing code. It would be a breaking change, so we can talk about doing that in v5.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Guard against SSR leaks in <Router> constructor · Issue #6363 ...
We should have a guard around the history.listen call in the constructor to be sure we are in a persistent environment first (see...
Read more >react-router-ssr - npm
react-router-ssr ... It has a protection against leaking your data. Only subscribed data will be available just the way it would be on...
Read more >Preventing Memory Leaks in Angular Observables with ...
Learn how to use ngOnDestroy to prevent memory leaks in your Angular JavaScript web applications.
Read more >SSR 5.5 Release Notes | SSN Docs
I95-48685 GUI and/or PCLI unresponsive: Resolved an issue where on an HA conductor the user interface would become unresponsive if a managed router...
Read more >Angular SSR - Cannot read properties of undefined (reading ...
Unsubscribe observables and detach event handlers to avoid memory leaks. Called just before Angular destroys the directive/component.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

Prior to the 4.4 changes, we did some wacky stuff with checking if we were in a staticContext or not. We could do the same thing to maintain the same behavior. 🤷♂️
Completely agree, @timdorr. I’m just concerned that someone might be relying on this behavior in a SSR scenario and we will break their app with 4.4 if we change it. Again, I’m totally down with changing this in v5.