-
Notifications
You must be signed in to change notification settings - Fork 0
Projects
A listing of ongoing and completed projects along with the version we expect them to be released. This is a "living" document. We'll update this as project statuses change or when new projects are added.
These are projects related to core functionality of React.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| complete | @sebmarkbage | 0.10 |
Make it so that components are cloned on mount, which ensures internal state and methods are being executed on the instance that we control. Methods calls can be forward to allow code working today to continue but with warnings.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| in progress | @sebmarkbage | 0.11 |
Return value of render will be a descriptor and not an actual instance.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @sebmarkbage | 0.12 |
Class instances will be decoupled from React core. You can use any custom abstraction for creating classes including ES6 classes. We'll provide recommended helpers for use with ES6 classes as the default way.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @sebmarkbage | 0.12 |
Internal methods (like mountComponent and receiveComponent) will move off the classes instances themselves and will part of the React mount runtime. The public class instances don't drive the runtime, they're passive. This makes it easier to make custom runtimes and support multi-environments beyond just DOM trees. Public API remains the same.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| in progress | @petehunt | #1554 | 0.11 |
On the surface refs are simple, but there are lots of problems once you get past the simple cases, namely the dependency on being mounted leads to inconsistent state. We may be able to solve this with callbacks and moving management to the owner.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @petehunt | 0.10 |
It's pretty much done. We should just expose it in addons.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| 0.11 |
It has its uses but it’s often not the right hammer for the job. We need finer grained control of prop merging. We may not be able to completely remove the use case for it, but the goal is to make it easier to do the common case.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| 1.0 |
This is tightly coupled to the other projects here. We’ll see how it shakes out.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| in progress | @jeffmo | #74, #760, #1221 | 0.11 |
Make it possible to transform into functions that aren’t in immediate scope. eg. <Namespace.Component />
This isn't actually related to core functionality of React, but has a large impact on how people use React.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| 0.12 |
setState currently takes a callback which gets called at some point. Sometimes it’s async, sometimes it’s not. We need a consistent way to expose pending state to be able to reason about things properly. We could perhaps use ES6 microtasks to implement this.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| 0.12 |
Right now we have a separate build due to the way we package things. Ideally we’ll get to a point with the public API that we can ship addons as standalone files / npm packages.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @chenglou | >1.0 |
This is a hard problem and we’re doing some experimentation here. React.addons.CSSTransitionGroup solves the most basic problems, but anything complicated is still unsolved.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @jeffmo |
Migrate React to use the same test runner we have internally. The goal here is that we have a consistent testing experience across our repositories and projects.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @jgebhardt | 1.0 |
We had updated designs and interactions for the home page months ago but didn’t do anything with them. We’ve also discussed moving off of GitHub pages and allowing for dynamic content. Some other things that could go on the site: nightly builds, performance test results, custom builds, component library.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @zpao | 1.0 |
Related to finalized API, it would be great to have auto-generated API docs. This will make versioning docs much easier.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| @zpao | * |
With multiple interdependent projects in the same repo, we have a bit of a mess. I don’t think it hurts much to have these things together, but we should make this as clear as possible.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| * |
We have a bunch of tests being run for this, but we’re not doing anything with this data and the tests we have aren’t great indicators.
| Status | Owner | Issues | Target Version |
|---|---|---|---|
| * |
Occasionally we’ll make a change in open source that breaks things internally at Facebook. This is because somebody wrote code in a way we didn’t clearly say wasn’t supported, and it worked. We should make sure we have tests for the way we want things to work. We should also make sure we have tests for the way things actually work so we can have more confidence in our test coverage.