-
Notifications
You must be signed in to change notification settings - Fork 616
Create deprecating-components.md #2733
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
size-limit report 📦
|
53927e1
to
aac770b
Compare
|
||
## Developing a draft component | ||
|
||
Start building the new component outside of the main bundle. This includes the source code of the component being under the `src/drafts` folder and the component being exported in the draft bundle (`src/drafts/index.ts`). That way, folks who |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see some of the drafts component under the src/drafts
and some not. Would that be true that we eventually want to have the practise to create the drafts components under the src/drafts
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@siddharthkp instead of recommending these components go into src/drafts
, do you think we should be encouraging folks to build directly in the new experimental components repo instead? https://github.com/github/experimental-react-components
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh super keen to hear about this 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes!
But given the change in direction for experimental-components, i'm not sure if it should be github/experimental-react-components
or our own primer/react-experimental
, another ADR? 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, probably. @justinbyo is going to be helping us figure out ownership models for shared React components looking forward.
In the meantime, are we comfortable shipping these docs with the direction to build direct in experimental-react-components
for now, and we can always update if/when we make a change? We don't seem to deprecate components super often so I'm thinking that changing this guidance later wouldn't be a huge problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point @broccolinisoup. In most cases we should have similar standards for components (including unit tests and Storybook) in the experimental-react-components
repo as we do in primer/react
. I'm admittedly not as familiar with all of the items in the checklist and whether they would apply exactly the same in experimental-react-components
; what do you think @siddharthkp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In most cases we should have similar standards for components (including unit tests and Storybook) in the experimental-react-components repo as we do in primer/react
I am a fan of this!
I wasn't sure how much we can "influence" experimental-react-components
to follow our Primer component standards.
From my observation, experimental-react-components
differ from PRC in the way of documenting components and they don't include some util unit test functions as PRC do.
Super keen to hear @siddharthkp's thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 thanks for DMing me! i've lost the fight against notifications.
I wasn't sure how much we can "influence" experimental-react-components to follow our Primer component standards.
Oooh, we definitely should influence it a lot. We can even assist (and enforce) practices by baking them into the react toolchain.
However, we also keep the barrier for contribution pretty low. Experimental components are meant to be pre-alpha in the lifecycle, more context in ADR 008
From my observation, experimental-react-components differ from PRC in the way of documenting components and they don't include some util unit test functions as PRC do.
Some of this, like the docs, is intentional, we chose storybook docs over doctocat to make it easier (and less elaborate) to document than primer. The lack of test functions isn't part of the strategy, that's just because we've only had one iteration of this till now :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooh, we definitely should influence it a lot. We can even assist (and enforce) practices by baking them into the react toolchain.
Awesome to hear!
However, we also keep the barrier for contribution pretty low. Experimental components are meant to be pre-alpha in the lifecycle, more context in ADR 008
This is a pretty good point!
Some of this, like the docs, is intentional, we chose storybook docs over doctocat to make it easier (and less elaborate) to document than primer. The lack of test functions isn't part of the strategy, that's just because we've only had one iteration of this till now :)
Gotcha!
It feels to me that moving experimental components from react-experimental-components
is a slightly different process than deprecating components, especially around the practises.
Another question - if an existing component was to be re-written by a Primer engineer (following all Primer standards), would we still start in the experimental-react-components
repo or in our own repos?
cc @lesliecdubs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello! @siddharthkp and @lesliecdubs
Seems like we still have questions regarding to experimental-react-components
repo's practises and how they will make their way to Primer. Would it be okay to go ahead with this section as is (creating the components in the drafts
folder) until we have a clear practise for experimental-react-components
? At least we will treat this document as the current practise and we can update as we go?
|
||
Once the major release is out, we provide support on how to switch using the newly develop component as well as how to continue to use the deprecated component for folks who prefer to migrate later on. | ||
|
||
We also write codemods to deprecate the old component and use the new component under [our migration repo](https://github.com/primer/react-migrate#readme). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we provide any other support for teams except proving these codemods? Do they actually go and update the usages themselves or do we do it?
Also, is there any other practise we do or would like to introduce to encourage teams switching using the new components?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for writing this up!
|
||
## Developing a draft component | ||
|
||
Start building the new component outside of the main bundle. This includes the source code of the component being under the `src/drafts` folder and the component being exported in the draft bundle (`src/drafts/index.ts`). That way, folks who |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@siddharthkp instead of recommending these components go into src/drafts
, do you think we should be encouraging folks to build directly in the new experimental components repo instead? https://github.com/github/experimental-react-components
Co-authored-by: Leslie Cohn-Wein <lesliecdubs@github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! I feel like this documents my understanding of the current deprecation process 👍 Just left a grammar suggestion and a note on the FAQ 👀
## FAQ | ||
|
||
- Does the deprecated component accept new feature request? | ||
- No, because we have a single bundle for all components, you can not pick the components you want to upgrade. This can result in additional unrelated work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be helpful to highlight that, once deprecated, the component is likely in a "maintenance mode" and will only receive bug fixes. Maybe something like:
- No, because we have a single bundle for all components, you can not pick the components you want to upgrade. This can result in additional unrelated work. | |
- No, once a component is deprecated the only changes it will receive are bug fixes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do y'all think: should this be will receive or may receive? Not sure how dedicated we've been to handling all bugfixes in deprecated components, or just major functional bugs 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"may receive" sounds good to me. I like that it removes the certainty.
I updated to be "may receive" but please let me know if anyone has a concern 🙌🏻
|
||
### Comms side of the deprecation | ||
|
||
When Primer team is ready to promote the newly developed component in the main bundle and the component v1 is good to be deprecated in the next major release, team announces the deprecation and the promotion in the [Primer changelog](https://github.com/github/primer/discussions/categories/primer-changelog) (GitHub staff only) under the `Coming soon` section and release a technical preview. Please see an example of the [technical preview announcement for the v35](https://github.com/primer/react/discussions/1918). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated this section to reflect @rezrah's comments on versioning docs ✨
@@ -0,0 +1,91 @@ | |||
# Deprecating and promoting components in Primer React |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if "Promoting" a good word for describing the process to move the deprecated component into the deprecated bundle. I thought it would be good to separate the process of deprecation (as in adding a @deprecated
annotation) and moving the component into the deprecated folder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @colebemis
I'd like to move forward with this PR if that is okay. This reflects the current process - We will need to come back and update the documentation around creating the components under the @lesliecdubs Since you requested changes before, it needs your approval 😇 Thank you! |
Closes https://github.com/github/primer/issues/1593
This PR is based on deprecating React components ADR , my notes from chatting with PRC folks about the process as well as my first time deprecating a component experience. So this is a pretty much raw document that I would love to get your thoughts on 🙏🏼
Note: I copy-pasted quite a few info from the ADR, thanks to @siddharthkp :)
Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.