[Fiber][WIP] Shallow Renderer #8808
Conversation
Will need to remove the owner properly, this is just a proof-of-concept commit. Getting to know the codebase.
| } | ||
|
|
||
| getRenderOutput() { | ||
| const hasChildren = this.container.children.length > 0; |
There was a problem hiding this comment.
The conceptual problem here is composites (e.g. <Foo />) will never end up as children. At least not unless we let the renderer somehow override the resolved element type from function to string conditionally.
There was a problem hiding this comment.
Not sure I follow. This is the "container's" children, which should be the component's root element. Unless I'm mistaken...? This is a very early PR btw. Still wrapping my head around how Fiber works internally :)
There was a problem hiding this comment.
Maybe too much info/review but:
- Composite components are the capitalized components like
<Foo /> - Host components are the lowercase ones like
<div />
I think what @gaearon is saying is that as a fiber renderer you don’t ever actually get to see the composite components because those are all happened internally so the children you see are the reconciled host component descriptions.
|
Is there any chance ShallowRenderer with Fiber supports all lifecycle methods like #7912? |
|
I would expect that this implementation will be closer to "real" DOM rendering in terms of lifecycle and stuff since it's less hacky. |
|
That's so nice! I think that makes it easy to add Fiber support into enzyme. |
|
Not sure to be honest. I don't know what's required on Enzyme side but I think they were reaching into internals quite a bit in the past. cc @lelandrichardson @ljharb for thoughts if you have any? |
|
@gaearon It's actually not too bad. The only The other sin that we commit is to use a lot of internal properties and data structures (ie, internal component instances) that are subject to change in react for traversal and such. If we can align on this that will also be a non-issue. |
Right, so the problem here is that those are very different in Fiber. Can you point me to the code that traverses the internal structures? Do they absolutely need to be exposed (even via an adapter)? For which use cases? |
|
@gaearon You can see most of it in this file. If you grep for
Well, it depends. Most of this could be abstracted away by the |
|
Do you think somebody from Enzyme could collaborate with us and send the PRs to test renderer to implement what’s missing so that you don’t have to access internal structures? This would make everything so much simpler. I’m happy to provide the necessary guidance. |
|
@gaearon yes, definitely :) I've actually already got a branch locally that does this, but I have to update it to reflect my changes to that RFC last night. |
|
Ooh neat. Do keep us updated. Also @iamdustan might be interested in helping out given he’s implemented the Fiber version of RTR. |
|
@gaearon will do! If everything in that RFC looks reasonable to you all, i'll try and get a PR up ASAP. Probably wouldn't be until thursday, though. |
|
Happy to help with and/or review when ready @lelandrichardson! |
|
In the end we went with not using Fiber for that and writing a standalone shallow renderer with no dependencies on other code. |
A very early PR, just to keep track of it.