Flow diagram of component lifecycle. #2184
Comments
|
There is such a diagram. @zpao |
|
@chenglou If this diagram could be shared here or put up online on the docs page I think a lot of people would appreciate it. I'm about to attempt some |
|
@chenglou Can you find me a good place to put it? |
|
http://facebook.github.io/react/docs/component-specs.html#lifecycle-methods |
|
This would still be appreciated... looks like the referencer of this issue and this issue were both closed but without the discussed resolution. Was that deliberate? |
|
@thechrisproject This issue is still open. |
|
@spicyj Ah, 951 is closed. Sorry about that! I'm fairly new to using github, I read that 'closed' as 'the state for this issue transitioned to closed here' |
|
Is the diagram real? Just posting it to this issue would be better than nothing. |
|
Here's a quick attempt in case it provides some inspiration... https://gist.github.com/chris-martin/2424924e7a7494d5f98c |
|
Here's my take on it, hopefully someone will find it handy: http://codepen.io/eduardoboucas/full/jqWbdb/ |
|
@eduardoboucas very cool, love the interactive format! |
|
@eduardoboucas looks very good! |
|
New reference lists lifecycles by phase:
I think we can close this. |
See context from #2187 for background about control dependencies. Our current `PruneNonReactiveIdentifiers` pass runs on ReactiveFunction, after scope construction, and removes scope dependencies that aren't reactive. It works by first building up a set of reactive identifiers in `InferReactiveIdentifiers`, then walking the ReactiveFunction and pruning any scope dependencies that aren't in that set. The challenge is control variables, as demonstrated by the test cases in #2184. `InferReactiveIdentifiers` runs against ReactiveFunction, and when we initially wrote it we didn't consider control variables. To handle control variables we really need to use precise control- & data-flow analysis, which is much easier with HIR. This PR adds the start of `InferReactivePlaces`, which annotates each `Place` with whether it is reactive or not. This allows the annotation to survive LeaveSSA, which swaps out the identifiers of places but leaves other properties as-is. This version does _not_ yet handle control variables, but it's already more precise than our existing inference. In our current inference, if `x` is ever assigned a reactive value, then all `x`s are marked reactive. In our new inference, each instance of `x` (each Place) gets a separate flag based on whether x can actually be reactive at that point in the program. There are two main next steps (in follow-up PRs): * Update the mechanism by which we prune non-reactive dependencies from scopes. * Handle control variables. I think we may be able to use dominator trees to figure out the set of basic blocks whose reachability is gated by the control variables. This should clearly work for if/else and switch, as for loops i'm not sure but intuitively it seems right.
For new developers such as myself understanding exactly when component functions are called, such as
shouldComponentUpdateandrender, can be very confusing. I have readhttp://facebook.github.io/react/docs/component-specs.htmlmany times but have failed to piece together a coherent image.Is there a more detailed reference that perhaps contains diagrams?
If not it would be a great thing to have. In the meantime I could read the source but I think would benefit others.
Thanks
The text was updated successfully, but these errors were encountered: