Conversation
|
Pull request demo site: URL |
📊 Bundle size report✅ No changes found |
marcosmoura
changed the title
marcosmoura
changed the title
docs/react-v9/contributing/rfcs/react-components/convergence/react-18-upgrade.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Victor Genaev <vgenaev@gmail.com>
|
|
||
| #### Cons | ||
|
|
||
| - 👎 The biggest challenge is how we currently communicate our library to partners. We have the explicit (and sometimes implicit) nomenclature "Fluent UI v9" everywhere, including chats, meetings, documents, e-mails, pipelines, folder structures and more. Even the root folder where this RFC document is located receive the react-v9 prefix.\ |
There was a problem hiding this comment.
the problem is not only with communication - applications often integrate code from various code repositories and this makes the promise of no breaking changes important - Package A comes from repo 1 and uses a new version of the code. Package B comes from repo 2 and uses an old version of the code. eventually both packages come to one app and need to work together, in some cases without the possibility of having multiple versions of dependencies bundled. Coordinating versions across different repos is a difficult challenge.
|
|
||
| - 👎 It would require some strategy to deprecate this compat package in the future | ||
| - 👎 Could bring some confusion to partners on why this is necessary | ||
| - 👎 Same other cons as option 1-a |
There was a problem hiding this comment.
I don't see any cons explicitly listed in option 1-a
|
|
||
| #### Pros | ||
|
|
||
| - 👍 Avoid the fear of a new major release |
There was a problem hiding this comment.
as far as I understand this would have same implications for consumers as having a new major version. the challenge is not with communication, the challenge is with shipping two incompatible APIs in one app together
3 participants
This is a WIP PR to concentrate the work on writing the RFC for the upcoming React 18 support