history.listen() v4 -> v5 compatibility

[richardgorman]

Hi, I noticed a change in the history.listen method.

The change is on this line: https://github.com/ReactTraining/history/pull/751/files#diff-c427a522f4ea08a4c045a518ac721ce9R34

history.listen((location, action) => {}) is now history.listen(({ location, action }) => {})

If there is no reason to this change except syntax sugar then I would like to suggest to revert this.

Reason: If you have an application where the history instances are swappable then it would be great to allow v4 and v5 instances to be interchangeable. That way a developer can elect to use an older version of the package to gain back some removed features (like basename support).

With this change anyone that wants to do that now has to change their code to be compatible.

[miraage]

With this change anyone that wants to do that now has to change their code to be compatible.

That's why SemVer exists. Updating from v4 to v5 is a breaking change by default. https://semver.org/#spec-item-8

[jaydenseric]

I'm ok with breaking changes, what is frustrating is that this very breaking change is not mentioning in the v5.0.0 release notes under “Breaking Changes”:

https://github.com/ReactTraining/history/releases/tag/v5.0.0

[joshxyzhimself]

yea it's a fucking headache to deal with

[joshxyzhimself]

this history v5 and react router v6 is just a clusterfuck of migration to deal with

[danrot]

I also don't see the huge advantage of this change... However, changing it back would be another BC break, causing more headaches for people who have already changed it :see_no_evil: But it should definitely be mentioned in the release, I was reading the breaking changes and assumed that I won't need any migration, because the changes mentioned there didn't affect my application.

[arianitu]

Honestly, the JavaScript world is a big joke. Your only method to surviving dependency hell while using NPM/React and any other project is to do everything in house. Ignore the naysayers who talk about "reinventing the wheel"

In the JavaScript world, if you don't do everything in house, your project will survive about 6 months before everything breaks when you upgrade your dependencies.

[imagine10255]

It’s too ridiculous... I have changed all the changes needed in the project... But the basename doesn’t support it, making me dumbfounded

[joshxyzhimself]

Honestly, the JavaScript world is a big joke. Your only method to surviving dependency hell while using NPM/React and any other project is to do everything in house. Ignore the naysayers who talk about "reinventing the wheel"

In the JavaScript world, if you don't do everything in house, your project will survive about 6 months before everything breaks when you upgrade your dependencies.

Hella agree this one. Breaking changes taught us the hard way that we should keep the core stuff MINIMAL and STABLE.

Open source projects tend to serve a lot of projects hence the bloat and breakages. Sometimes it makes sense to pin dependencies or just extract the parts you need (with proper attribution of course).