├── 0000-template.md ├── LICENSE.md └── README.md /0000-template.md: -------------------------------------------------------------------------------- 1 | - Start Date: (fill me in with today's date, YYYY-MM-DD) 2 | - RFC PR: (leave this empty) 3 | - React Issue: (leave this empty) 4 | 5 | # Summary 6 | 7 | Brief explanation of the feature. 8 | 9 | # Basic example 10 | 11 | If the proposal involves a new or changed API, include a basic code example. 12 | Omit this section if it's not applicable. 13 | 14 | # Motivation 15 | 16 | Why are we doing this? What use cases does it support? What is the expected 17 | outcome? 18 | 19 | Please focus on explaining the motivation so that if this RFC is not accepted, 20 | the motivation could be used to develop alternative solutions. In other words, 21 | enumerate the constraints you are trying to solve without coupling them too 22 | closely to the solution you have in mind. 23 | 24 | # Detailed design 25 | 26 | This is the bulk of the RFC. Explain the design in enough detail for somebody 27 | familiar with React to understand, and for somebody familiar with the 28 | implementation to implement. This should get into specifics and corner-cases, 29 | and include examples of how the feature is used. Any new terminology should be 30 | defined here. 31 | 32 | # Drawbacks 33 | 34 | Why should we *not* do this? Please consider: 35 | 36 | - implementation cost, both in term of code size and complexity 37 | - whether the proposed feature can be implemented in user space 38 | - the impact on teaching people React 39 | - integration of this feature with other existing and planned features 40 | - cost of migrating existing React applications (is it a breaking change?) 41 | 42 | There are tradeoffs to choosing any path. Attempt to identify them here. 43 | 44 | # Alternatives 45 | 46 | What other designs have been considered? What is the impact of not doing this? 47 | 48 | # Adoption strategy 49 | 50 | If we implement this proposal, how will existing React developers adopt it? Is 51 | this a breaking change? Can we write a codemod? Should we coordinate with 52 | other projects or libraries? 53 | 54 | # How we teach this 55 | 56 | What names and terminology work best for these concepts and why? How is this 57 | idea best presented? As a continuation of existing React patterns? 58 | 59 | Would the acceptance of this proposal mean the React documentation must be 60 | re-organized or altered? Does it change how React is taught to new developers 61 | at any level? 62 | 63 | How should this feature be taught to existing React developers? 64 | 65 | # Unresolved questions 66 | 67 | Optional, but suggested for first drafts. What parts of the design are still 68 | TBD? -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2013-present, Facebook, Inc. 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # React RFCs 2 | 3 | Many changes, including bug fixes and documentation improvements can be 4 | implemented and reviewed via the normal GitHub pull request workflow. 5 | 6 | Some changes though are "substantial", and we ask that these be put 7 | through a bit of a design process and produce a consensus among the React 8 | core team. 9 | 10 | The "RFC" (request for comments) process is intended to provide a 11 | consistent and controlled path for new features to enter the project. 12 | 13 | [Active RFC List](https://github.com/reactjs/rfcs/pulls) 14 | 15 | React is still **actively developing** this process, and it will still change as 16 | more features are implemented and the community settles on specific approaches 17 | to feature development. 18 | 19 | ## Contributor License Agreement (CLA) 20 | 21 | In order to accept your pull request, we need you to submit a CLA. You only need 22 | to do this once, so if you've done this for another Facebook open source 23 | project, you're good to go. If you are submitting a pull request for the first 24 | time, just let us know that you have completed the CLA and we can cross-check 25 | with your GitHub username. 26 | 27 | **[Complete your CLA here.](https://code.facebook.com/cla)** 28 | 29 | ## When to follow this process 30 | 31 | You should consider using this process if you intend to make "substantial" 32 | changes to React or its documentation. Some examples that would benefit 33 | from an RFC are: 34 | 35 | - A new feature that creates new API surface area, and would 36 | require a feature flag if introduced. 37 | - The removal of features that already shipped as part of the release 38 | channel. 39 | - The introduction of new idiomatic usage or conventions, even if they 40 | do not include code changes to React itself. 41 | 42 | The RFC process is a great opportunity to get more eyeballs on your proposal 43 | before it becomes a part of a released version of React. Quite often, even 44 | proposals that seem "obvious" can be significantly improved once a wider 45 | group of interested people have a chance to weigh in. 46 | 47 | The RFC process can also be helpful to encourage discussions about a proposed 48 | feature as it is being designed, and incorporate important constraints into 49 | the design while it's easier to change, before the design has been fully 50 | implemented. 51 | 52 | Some changes do not require an RFC: 53 | 54 | - Rephrasing, reorganizing or refactoring 55 | - Addition or removal of warnings 56 | - Additions that strictly improve objective, numerical quality 57 | criteria (speedup, better browser support) 58 | - Additions only likely to be _noticed by_ other implementors-of-React, 59 | invisible to users-of-React. 60 | 61 | ## What the process is 62 | 63 | In short, to get a major feature added to React, one usually first gets 64 | the RFC merged into the RFC repo as a markdown file. At that point the RFC 65 | is 'active' and may be implemented with the goal of eventual inclusion 66 | into React. 67 | 68 | * Fork the RFC repo http://github.com/reactjs/rfcs 69 | * Copy `0000-template.md` to `text/0000-my-feature.md` (where 70 | 'my-feature' is descriptive. Don't assign an RFC number yet). 71 | * Fill in the RFC. Put care into the details: **RFCs that do not 72 | present convincing motivation, demonstrate understanding of the 73 | impact of the design, or are disingenuous about the drawbacks or 74 | alternatives tend to be poorly-received**. 75 | * Submit a pull request. As a pull request the RFC will receive design 76 | feedback from the larger community, and the author should be prepared 77 | to revise it in response. 78 | * Build consensus and integrate feedback. RFCs that have broad support 79 | are much more likely to make progress than those that don't receive any 80 | comments. 81 | * Eventually, the team will decide whether the RFC is a candidate 82 | for inclusion in React. 83 | * RFCs that are candidates for inclusion in React will enter a "final comment 84 | period" lasting 7 days. The beginning of this period will be signaled with a 85 | comment and tag on the RFCs pull request. 86 | * An RFC can be modified based upon feedback from the team and community. 87 | Significant modifications may trigger a new final comment period. 88 | * An RFC may be rejected by the team after public discussion has settled 89 | and comments have been made summarizing the rationale for rejection. A member of 90 | the team should then close the RFCs associated pull request. 91 | * An RFC may be accepted at the close of its final comment period. A team 92 | member will merge the RFCs associated pull request, at which point the RFC will 93 | become 'active'. 94 | 95 | ## The RFC life-cycle 96 | 97 | Once an RFC becomes active, then authors may implement it and submit the 98 | feature as a pull request to the React repo. Becoming 'active' is not a rubber 99 | stamp, and in particular still does not mean the feature will ultimately 100 | be merged; it does mean that the core team has agreed to it in principle 101 | and are amenable to merging it. 102 | 103 | Furthermore, the fact that a given RFC has been accepted and is 104 | 'active' implies nothing about what priority is assigned to its 105 | implementation, nor whether anybody is currently working on it. 106 | 107 | Modifications to active RFCs can be done in followup PRs. We strive 108 | to write each RFC in a manner that it will reflect the final design of 109 | the feature; but the nature of the process means that we cannot expect 110 | every merged RFC to actually reflect what the end result will be at 111 | the time of the next major release; therefore we try to keep each RFC 112 | document somewhat in sync with the language feature as planned, 113 | tracking such changes via followup pull requests to the document. 114 | 115 | ## Implementing an RFC 116 | 117 | The author of an RFC is not obligated to implement it. Of course, the 118 | RFC author (like any other developer) is welcome to post an 119 | implementation for review after the RFC has been accepted. 120 | 121 | If you are interested in working on the implementation for an 'active' 122 | RFC, but cannot determine if someone else is already working on it, 123 | feel free to ask (e.g. by leaving a comment on the associated issue). 124 | 125 | ## Reviewing RFCs 126 | 127 | Each week the team will attempt to review some set of open RFC 128 | pull requests. 129 | 130 | We try to make sure that any RFC that we accept is accepted at the 131 | weekly team meeting. Every accepted feature should have a core team champion, 132 | who will represent the feature and its progress. 133 | 134 | **React's RFC process owes its inspiration to the [Yarn RFC process], [Rust RFC process], and [Ember RFC process]** 135 | 136 | [Yarn RFC process]: https://github.com/yarnpkg/rfcs 137 | [Rust RFC process]: https://github.com/rust-lang/rfcs 138 | [Ember RFC process]: https://github.com/emberjs/rfcs 139 | --------------------------------------------------------------------------------