Upcoming breaking changes (v14)

[emmenko]

In the next major release I would like to go with first support for hooks, which will help us to ship less and more performant code.
Therefore, we should:

• support only react >16.8.0
• use hooks in the appkit packages implementations, easier to type as well
• I would also like to drop the HOC functions

We can maybe do the same in the upcoming uikit v10 and release both versions together.

Also maybe upgrade RTL.

Thoughts?

---

• peer dependency react >16.8 [v14] chore: bump react peer deps to >=16.8 (hooks support) #795
• peer dependency react-redux >7 [v14] chore: require v7 for react-redux peer dep #853
• (check if it's worth it, otherwise deprecate it for now) remove HOCs
• (optional) use hooks in all appkit packages
• (optional) use hooks for notifications [v14] refactor(react-notifications): to use hooks #855
• (optional) use hooks for redux [v14] feat(actions-global): expose hooks for dispatching notifications #852
• (optional) use hooks for l10n [v14] refactor(l10n): to implement loading data with hooks, refactor internals of HOCs #860
• (optional) upgrade to react-intl v3 [v14] refactor: upgrade to react-intl v3, refactor some components and tests, fix project-switcher #799 [v14] chore: bump react-intl to 3.0.0-beta.14 #817
• (optional) upgrade to react-apollo v3 [v15] refactor(app-shell): use react-apollo v3 #801
• (check the effort) upgrade to latest RTL -> @testing-library/react [v14] chore: upgrade RTL to @testing-library/react v8.x #811
• upgrade ct enzyme-extensions dep in jest to latest (for the renderProp) [v14] chore(jest-preset): bump enzyme-extensions dep to v5 #796
• (optional) rename assets files refactor(assets): rename images #834
• peer dependency uikit >10 [v14] migrate to uikit v10 #825
• migrate uikit v10 breaking changes [v14] migrate to uikit v10 #825
• remove IE11 specific polyfills and ponyfills v14 -> refactor(mc-scripts): dump polyfills #830
• stop transpiling for IE 11 [v14] refactor(mc-scripts): to remove IE from browserslit #836
• remove vendorsToTranspile webpack option v14 -> refactor: remove vendorsToTranspile #829
• update permissions constants to match new permissions (e.g. ManageProject has been removed) [v14] refactor(permissions): to remove permission constants and drop ManageProject support #815
• deprecate storage package [v14] Deprecate storage package #828
• remove deprecated components: ServicePageResponseLayout [v14] Deprecate storage package #828

[tdeekens]

I like it. Hope that people will update. However, I feel there are other reasons than bumping react why some projects do not get updated. To be fair, I don‘t think hooks for hocs will show meaningful performance improvements. It will make code easier to type and read for sure.

[emmenko]

Yeah, for the performance I mean more from the React side of things. For example less wrapping components, probably react can even further optimize things internally (just a hunch from my side).
Also Babel will generate less code 🙌

[montezume]

I would like to remove all of the usages HOCs from UI-Kit. withMouseOver etc can be done with pure css instead of using JavaScript.

[montezume]

Can we also make sure we include the assets renaming?

#546

🙏

[emmenko]

Short update: I've been trying to migrate the notifications package to TS and typing redux middlewares is kind of a nightmare.
That led me to consider refactoring the package to use hooks (including redux hooks), which makes it also easier to type.
Therefore, I would like to include those changes in this new release, or at least from this release onwards.

[emmenko]

Short update: I tried to use react apollo hooks (#801), which are supported by the upcoming react-apollo v3 (currently in beta). This lead to having to update react to 16.9 (currently in alpha) and RTL to latest (@testing-library/react).
Upgrading those dependencies require some extra work. We also need to coordinate how we should migrate the mc-fe apps to those versions.

We might decide to skip those updates in the v14 release but we will eventually need to do that in a next major (for instance, uikit should do the same).

[montezume]

Hm, UI-Kit already uses the latest @testing-library/react, and it doesn't use apollo. 😕

[emmenko]

Ah ok...it's also react to be updated...but anyway, as long as we keep in sync it should not matter

[tdeekens]

I am being a bit pungent again. Should we finish the static typing story and then move on to this [working on releasing v14]. Sometimes I feel we just jump onto whatever we feel would be most fun or interesting but also beneficial. However, we should put ourselves to the same standards and ideals we communicate towards others: finish before starting.

[montezume]

@tdeekens by this are you referring to updating mc-fe to latest RTL, or are you referring to releasing a major app kit release?

[tdeekens]

Sorry, for releasing a major version of app-kit. I am all for planning it and thinking about it. Still, I wonder why we start it before we finish the static typing story. In all splitting and jumping between those "projects" just diffuses energy and effort and increases the likihood of leaving either or in a have finished state.

[montezume]

Well, we need a major version of app kit to update UI-Kit though, and we have spent a lot of energy preparing for the next major UI-Kit...

[montezume]

I understand your concerns about starting new things and not finishing, but we can't suffer from release paralysis. Sometimes we need to release breaking changes, and some of the time it's not even coming from the developers side, but from the designers, etc.

[tdeekens]

Sometimes we need to release breaking changes, and some of the time it's not even coming from the developers side, but from the designers, etc.

It's not about breaking changes. It's about focusing in on something else started and finishing it. If this now became more important as UIKit depends on it, then that's a valid reason to not work on typing more right now.

[emmenko]

The static typings was something we agreed on doing "on the side", as it's not a high priority task. The v14 release is more important to finish first, as it brings more direct benefits.

With that in mind, in general start finishing before starting still stands of course!

[montezume]

We can also progressively (on the side if you will) migrate App Kit to hooks once the breaking change is released requiring React 16.8. 😄

[emmenko]

Should we include latest RTL in this release? I don't think we can really upgrade the mc-fe separately, as the app-shell test-utils rely on a specific rtl version.