Please provide an official rationale for locking #5076

[binki]

Hi,

After reading to the end of #5076, I see that the conversation was locked by the project maintainers without giving a rationale or guidance for others who come to the issue. There are those of us who are coming to the issue and experiencing the OP’s pain of how the current react-router API “completely ruins modularity” and forces one to suffer a “full-scale elimination of the concept of pure components” to get an app to function at all. There is no guidance for us from official project maintainers. I’d expect the maintainers to either:

1. Explain how the maintainers came to the conclusion that the issue is spam and needed locking without comment. This will help us users of react-router to better evaluate our scenarios issues so that we can come to the conclusion that our requests are spam and avoid filing them in the first place.
2. Or provide a solution to the issue acceptable to people sharing the OP’s sentiments (which would probably eliminate the need for the issue to be locked).

Thanks.

[timdorr]

I lock old discussions that have petered out and get necro-posted by passers-by coming in from Google. It's a cleanup thing, not a suppression thing. If there is new discussion to be had, please post a new issue. New discussion topics, even if they've been discussed before are not automatically closed, provided they're bringing something new to the table.

As for the issue at hand, the problem is at a higher level than this project. Here's a rundown of the problem (with a solution): https://github.com/ReactTraining/react-router/blob/master/packages/react-router/docs/guides/blocked-updates.md

The good news is React is providing us a solution in 16.3. We're going to implement it (#5901) and it should be out in the following minor release.