4 ms·
It can be more complex than that. When we shipped React-Redux v8, we rewrote our internals to drop our own subscription management logic, and switched to React
by acemarke 2y ago
It can be more complex than that.
When we shipped React-Redux v8, we rewrote our internals to drop our own subscription management logic, and switched to React's new `useSyncExternalStore` hook instead. However, `uSES` only was added with React 18, and we still wanted to support earlier versions of React that had hooks (16.8+, 17). So, we defaulted to using React's "shim" package that provided a backwards-compatible implementation of `usES`, at the cost of a bit of extra bundle size.
Once React 18 reached sufficient adoption, we wanted to drop the use of the `uSES` shim package and use the built-in version, but that required React 18 as a minimum dependency. So, we did that in a major, React-Redux v9.
Code _using_ React-Redux never changed in the slightest - it's still the same `useSelector` calls either way. But given that anyone attempting to mix React-Redux v9 and React <=17 would have it break, that was clearly a major version bump for us.
- swyx 2y ago> Deprecating "legacy APIs", from the perspective of the API users, _is_ breaking core functionality. Functionality that existed previously is now gone, that is a breaking change. gotta love hyrums law
- RadiozRadioz 2y agoIn this case, yes, major is warranted. This type of dependency is different to what I wrote about. I was talking about dependencies of your library that are fully internal and hidden from its users, whereas this example is much wider and closer to a dependency on the environment in which your library is being used.