Skip to content

[WIP] ReactNativeFiber mixins refactor #9013

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

bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Feb 15, 2017

Note This PR has changed significantly since it was initially created. (See commit history for more.)

Addressed a circular dependency between NativeMethodsMixin and ReactNativeFiber:

  • Created new ReactNativeFiberHostComponent with similar interface but without unnecessary call to findNodeHandle.
  • Created new Flow interface for mixins to ensure ReactNativeFiberHostComponent and NativeMethodsMixinUtils stay synced.
  • Moved helper methods to NativeMethodsMixinUtils to be shared between the 2 wrappers.

Fixed bug in createReactNativeComponentClass that allowed duplicate view names to be registered and added a unit test to guard against a regression.

@sebmarkbage
Copy link
Collaborator

We actually have a task to undo all the tests that reach into internals like this. :) It makes refactoring harder.

You can express this using public APIs. You can test the first two by calling createReactNativeComponentClass.

You can test the last one by rendering a view like <foo /> using the renderer.

@bvaughn
Copy link
Contributor Author

bvaughn commented Feb 15, 2017

Yeah, I considered testing with createReactNativeComponentClass but the behavior varies between fiber and stack. (Stack doesn't error.)

@sebmarkbage
Copy link
Collaborator

That's an argument for doing it so that we're aware of the differences. It might actually be a problem for us because people copy paste stuff into their own modules. Not guaranteed to have unique names. Would be better with an incremental counter.

Copy link
Collaborator

@sebmarkbage sebmarkbage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add a test for the public API behind a feature flag like we've done in other places if needed.

I don't think this is the strategy we should go with at all though since it can break the ecosystem when people load different modules. Worse case you load modules dynamically. If you test each feature in isolation you get no error. Then the end user visits both features in production and you get an error.

@sebmarkbage
Copy link
Collaborator

I suppose it's unlikely that you have two different modules targeting the same native uiViewClassName but it's possible.

@bvaughn
Copy link
Contributor Author

bvaughn commented Feb 15, 2017

I don't think this is the strategy we should go with at all though since it can break the ecosystem when people load different modules.

Yes, I agree. We could switch to some other uid (like a counter) to make this particular issue more robust, but there's also the related issue of native mixins so maybe this is a better time to re-think the return value of ReactNativeViewConfigRegistry.register

Let's sync up tomorrow at the office and talk more.

@bvaughn bvaughn force-pushed the ReactNativeViewConfigRegistry-invariant-check-fix branch from 8a3f00a to e2a0152 Compare February 16, 2017 00:42
@bvaughn bvaughn changed the title Fixed a bad invariant check in ReactNativeViewConfigRegistry Refactor how viewConfigs are handled for ReactNativeFiber Feb 16, 2017
@bvaughn bvaughn changed the title Refactor how viewConfigs are handled for ReactNativeFiber [WIP] Refactor how viewConfigs are handled for ReactNativeFiber Feb 16, 2017
fiber.type = type;
// @TODO (bvaughn) This is temporary hack just to get things working.
if (typeof type.__reactInternalHostComponentFlag !== 'undefined') {
fiber = createFiber(HostComponent, key);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope this doesn't stay for a couple of years like similar hacks have stayed in Stack :-)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the plan for unhacking this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is just me poking things a bit and familiarizing myself with the problem. Sebastian and I are going to talk more about it when he gets in this morning. 😄

gaearon added a commit to gaearon/react-devtools that referenced this pull request Feb 16, 2017
Not sure if that one gets merged but it fixes other issues so it's likely.
@bvaughn bvaughn force-pushed the ReactNativeViewConfigRegistry-invariant-check-fix branch 2 times, most recently from 38ff586 to f451cd2 Compare February 16, 2017 18:30
@janicduplessis
Copy link

janicduplessis commented Feb 19, 2017

There was a circular dependency that was causing a crash when running the Native Animated example in UIExplorer with Fiber, ReactNative -> NativeModulesMixin -> ReactNative. I was about to send a fix but I think this PR will also fix it.

Brian Vaughn added 2 commits February 28, 2017 12:47
…eturn wrapper object (like stack does) instead of string.

This is a work-in-progress. Pushing now for sharing purposes.
@bvaughn bvaughn force-pushed the ReactNativeViewConfigRegistry-invariant-check-fix branch from f451cd2 to b5e9614 Compare February 28, 2017 21:16
…ativeFiber:

• Created new ReactNativeFiberHostComponent with similar interface but without unnecessary call to findNodeHandle.
• Created new Flow interface for mixins to ensure ReactNativeFiberHostComponent and NativeMethodsMixinUtils stay synced.
• Moved helper methods to NativeMethodsMixinUtils to be shared between the 2 wrappers.

Added createReactNativeComponentClass test to ensure that ReactNativeFiber doesn't permit conflicting native view configs to be registered.
@bvaughn bvaughn force-pushed the ReactNativeViewConfigRegistry-invariant-check-fix branch from b5e9614 to ef36bf8 Compare February 28, 2017 21:23
@bvaughn bvaughn changed the title [WIP] Refactor how viewConfigs are handled for ReactNativeFiber [WIP] ReactNativeFiber mixins refactor Feb 28, 2017
This method depends on viewConfig, which used to be an instance property copied from the RN host component type. Now that this type is a string the viewConfig property is undefined for class components. The mixed-in setNativeProps method gets the view config from the nearest host component, which happens to also be the one the properties are set on.
@bvaughn
Copy link
Contributor Author

bvaughn commented Mar 8, 2017

I've moved this effort to an internal diff for now because it's easier to test its impact that way. I'm going to close this PR (since it's changed so much from the initial commit anyway) and I'll open a new one once the internal diff has been merged. 😄

@bvaughn bvaughn closed this Mar 8, 2017
@gaearon
Copy link
Collaborator

gaearon commented Mar 8, 2017

I'll open a new one once the internal diff has been merged

Wouldn't it just show up as a commit then? I don't think you need to do anything once internal diff lands.

@gaearon
Copy link
Collaborator

gaearon commented Mar 8, 2017

Oh, we're in React repo. Nevermind 😄

@bvaughn bvaughn deleted the ReactNativeViewConfigRegistry-invariant-check-fix branch March 27, 2017 15:41
bvaughn pushed a commit to facebook/react-devtools that referenced this pull request May 30, 2017
Not sure if that one gets merged but it fixes other issues so it's likely.
gaearon pushed a commit to facebook/react-devtools that referenced this pull request May 31, 2017
* Fix a crash due to facebook/react#9013

Not sure if that one gets merged but it fixes other issues so it's likely.

* Fix editing host styles in RN

Also switch it to use the same `updater` code path both in Stack and Fiber.
This removes knowledge about internal data structure from the frontend.

* Fully fix editing RN styles

* We shouldn't rely on the assumption that we're operating on current Fiber
* The idea to unify updaters with setInProps() was a bad one because setNativeProps() signature is too different

* Flow fixes; I think the correct thing to do is to use Dom's newer code over Dan's older code for setupBackend.
bestlucky0825 pushed a commit to bestlucky0825/react-devtools that referenced this pull request Jun 1, 2022
* Fix a crash due to facebook/react#9013

Not sure if that one gets merged but it fixes other issues so it's likely.

* Fix editing host styles in RN

Also switch it to use the same `updater` code path both in Stack and Fiber.
This removes knowledge about internal data structure from the frontend.

* Fully fix editing RN styles

* We shouldn't rely on the assumption that we're operating on current Fiber
* The idea to unify updaters with setInProps() was a bad one because setNativeProps() signature is too different

* Flow fixes; I think the correct thing to do is to use Dom's newer code over Dan's older code for setupBackend.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants