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
Copy React Reconciler modules to new fork #18548
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 168215d:
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 4c6470c:
|
ec82c91
to
a48cf16
Compare
Details of bundled changes.Comparing: 147bdef...4c6470c react-art
react-test-renderer
react-native-renderer
react-dom
react-reconciler
ReactDOM: size: 0.0%, gzip: 0.0% Size changes (stable) |
Details of bundled changes.Comparing: 147bdef...4c6470c react-art
react-test-renderer
react-dom
react-native-renderer
react-reconciler
Size changes (experimental) |
Some of our internal reconciler types have leaked into other packages. Usually, these types are treated as opaque; we don't read and write to its fields. This is good. However, the type is often passed back to a reconciler method. For example, React DOM creates a FiberRoot with `createContainer`, then passes that root to `updateContainer`. It doesn't do anything with the root except pass it through, but because `updateContainer` expects a full FiberRoot, React DOM is still coupled to all its fields. I don't know if there's an idiomatic way to handle this in Flow. Opaque types are simlar, but those only work within a single file. AFAIK, there's no way to use a package as the boundary for opaqueness. The immediate problem this presents is that the reconciler refactor will involve changes to our internal data structures. I don't want to have to fork every single package that happens to pass through a Fiber or FiberRoot, or access any one of its fields. So my current plan is to share the same Flow type across both forks. The shared type will be a superset of each implementation's type, e.g. Fiber will have both an `expirationTime` field and a `lanes` field. The implementations will diverge, but not the types. To do this, I lifted the type definitions into a separate module.
All changes in this commit were generated by the following commands. Copy each module that ends with `.old` to a new file that ends with `.new`: ```sh for f in packages/react-reconciler/src/*.old.js; do cp "$f" "$(echo "$f" | sed s/\.old/\.new/)"; done ``` Then transform the internal imports: ```sh grep -rl --include="*.new.js" '.old' packages/react-reconciler/src/| xargs sed -i '' "s/\.old\'/\.new\'/g" ```
Updates Rollup, Jest, and Flow configuration to point to the new entry points.
I'm going to land this while everyone is sleeping 😆 Normally I wouldn't do this but I'm making an exception since this affects such a large surface area and landing this in the middle of the day would be pretty churny / annoying to rebase. More rationalization: none of the implementation has changed, only infra stuff and shuffling of types. |
Builds on top of #18285. See that PR for context and motivation.
I suggest reviewing commit-by-commit.
.old
) modules. I'll land this to master in its own commit to preserve the history/blame..new
) modules. Forked modules are given a suffix of.old
ornew
. It does change any of the implementation. They are the same except for the imports. The changes in this commit are autogenerated. (Refer to the commit message for exact steps.)