Giters

reactjs / rfcs

RFCs for changes to React

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Feature request]: Allow local component replace

theKashey opened this issue · comments

commented

issue created after this tweet from Kent C. Dodds - https://twitter.com/kentcdodds/status/1254625792434171907
image

This is a big pain for me - there are a few situations when the majority the code has to be in the Provider, and the Provider should be somewhere on top, but without Consumers it does nothing, and has to reasons to exists.
Sometimes those Providers are placed above Routes just to stay untouched on page transitions.

In short - something should be places closer to the tree root, however is not required to "be".

Feature request

This is where two things I love meet each other - code splitting and hot module replacement.

👉 right now hot module replacement is letting you break the rule of hooks, or even completely rewrite component especially class-component(Fast Refresh just instantiate a new one) keeping the tree below.

  • 😕what about allowing breaking rule of hooks by specifying hooksKey. This will allow injecting more (hook based) logic to already created components without destroying them, or three below them.

like key will create a new tree branch, with a new component on top, hooksKey will drop local hooks state, allowing component to spin un in a new form.

  • 🤔what about allowing providing components families, so I would be able to replace one StateProvider by another StateProvider without unmounting the tree below. The code is already inside React, and only proper API to setup friendly components(from C++ friendly classes) is missing.

There will be a good side effect from it. For example lets take a standard example with React-Router, and Switch before everything - in this case header or aside or anything else would be inside the Route, inside the component, and would be recreated every time.
It's possible to mitigate this issue just using render prop, so there will be no "page component", and tree elements, kept between page transitions, will be kept, however it makes code a bit more complicated, and forces you to think.
Marking Pages as a family will keep similar pieces of tree below without any extra code. 👍

commented

Hi, thanks for your suggestion. RFCs should be submitted as pull requests, not issues. I will close this issue but feel free to resubmit in the PR format.