Skip to content

Commit c563088

Browse files
committed
feat: create react-inner-hooks rfc
1 parent f744f67 commit c563088

File tree

1 file changed

+313
-0
lines changed

1 file changed

+313
-0
lines changed

text/0000-inner-hooks.md

Lines changed: 313 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,313 @@
1+
- Start Date: 2022-02-06
2+
- RFC PR:
3+
- React Issue:
4+
5+
# Summary
6+
7+
Add a special props named innerHooks to React.Component and extend createElement.
8+
9+
# Basic example
10+
11+
Giving that, you want child prop using hooks combined with redux state and define useOptions as a hook followed by example.
12+
13+
```tsx
14+
export function useOptions = () => {
15+
const users = useSelector()
16+
return useMemo(() => {
17+
return users.map((user) => {
18+
return {
19+
id: user.id,
20+
label: user.name
21+
}
22+
})
23+
}, [users])
24+
}
25+
```
26+
27+
```tsx
28+
import { useOptions } from "./useOptions";
29+
30+
const Example = (props) => (
31+
<Parent>
32+
<Component
33+
innerHooks={() => ({
34+
options: useOptions(),
35+
})}
36+
/>
37+
</Parent>
38+
);
39+
```
40+
41+
nearly equals to
42+
43+
```tsx
44+
import { useOptions } from "./useOptions";
45+
46+
const Example = (props) => {
47+
const options = useOptions();
48+
return (
49+
<Parent>
50+
<Component options={options} />
51+
</Parent>
52+
);
53+
};
54+
```
55+
56+
but, they are different about execution scopes. The formar is in child scope and the latter is in parent scope.
57+
In addition, innerHooks prop must return partial props of the component.
58+
59+
# Motivation
60+
61+
Component often needs conditional renderning but hooks must be written before their even if they don't depend on the condition for [idempotent calling rule of hooks](https://reactjs.org/docs/hooks-rules.html).
62+
63+
OK:
64+
65+
```tsx
66+
const Example = (props) => {
67+
const options = useOptions();
68+
const { initialized, data } = useFetchData();
69+
if (!initialized) return null;
70+
return <Component {...data} options={options} />;
71+
};
72+
```
73+
74+
Bad:
75+
76+
```tsx
77+
const Example = (props) => {
78+
const { initialized, data } = useFetchData();
79+
if (!initialized) return null;
80+
const options = useOptions();
81+
return <Component {...data} options={options} />;
82+
};
83+
```
84+
85+
or
86+
87+
```tsx
88+
const Example = (props) => {
89+
const { initialized, data } = useFetchData();
90+
if (!initialized) return null;
91+
return <Component {...data} options={useOptions()} />;
92+
};
93+
```
94+
95+
This is not problem when component is small, but big one is tough to read.
96+
97+
```tsx
98+
const Example = (props) => {
99+
const options = useOptions()
100+
const [optionValue, setOptionValue] = useState()
101+
const {initialized, data} = useFetchData()
102+
const someValue = ''
103+
if (!initialized) return null
104+
return (
105+
<Component>
106+
<Child>
107+
<AnnoyedField
108+
value={someValue}
109+
onChange={someChange}
110+
class='test'
111+
otherProps
112+
/>
113+
<AnnoyedField
114+
value={someValue}
115+
onChange={someChange}
116+
class='test'
117+
otherProps
118+
/>
119+
<AnnoyedField
120+
value={someValue}
121+
onChange={someChange}
122+
class='test'
123+
otherProps
124+
/>
125+
<AnnoyedField
126+
value={someValue}
127+
onChange={someChange}
128+
class='test'
129+
otherProps
130+
/>
131+
<AnnoyedField
132+
value={someValue}
133+
onChange={someChange}
134+
class='test'
135+
otherProps
136+
/>
137+
<AnnoyedField
138+
value={someValue}
139+
onChange={someChange}
140+
class='test'
141+
otherProps
142+
/>
143+
<AnnoyedField
144+
value={someValue}
145+
onChange={someChange}
146+
class='test'
147+
otherProps
148+
/>
149+
<Select
150+
value={optionValue}
151+
onChange={setOptionValue}
152+
options={options}
153+
otherProps
154+
/>
155+
<AnnoyedField
156+
value={someValue}
157+
onChange={someChange}
158+
class='test'
159+
otherProps
160+
/>
161+
<AnnoyedField
162+
value={someValue}
163+
onChange={someChange}
164+
class='test'
165+
otherProps
166+
/>
167+
<Child/>
168+
</Component>
169+
) {...data} options={useOptions()} />
170+
}
171+
```
172+
173+
As the farther place it's used from definition, it's more tough to remember the variable name and we are forced to use editor's trick like code jump, bookmark, splited view, etc. Or scroll and switch page many times.
174+
175+
The RFC way can envelop independent hooks against others in narrower scope.
176+
177+
```tsx
178+
const Example = (props) => {
179+
// ... Omitted
180+
const {initialized, data} = useFetchData()
181+
if (!initialized) return null
182+
return (
183+
<Component>
184+
{/* ...Omitted */}
185+
<Select
186+
innerHooks={() => {
187+
const [optionValue, setOptionValue] = useState()
188+
const options = useOptions()
189+
return {
190+
options,
191+
value: optionValue,
192+
onChange: setOptionValue
193+
}
194+
}}
195+
otherProps
196+
/>
197+
{/* ...Omitted */}
198+
</Component>
199+
)
200+
```
201+
202+
And this is more useful to move the component to other place compared to the past. This example may be meaningless because state created by useState scope is very limited. It's for sake of simplicity. If you use wide scope state and handler like redux or recoil or widely-context, you'll find this feature powerful. Now we can use hooks in context instead of extracting components per container or context's consumer which tends to become a source of trouble about optimizing rendering and readability. For example, we can write context to the extent of root component scope without separationg files.
203+
204+
```tsx
205+
const Context = createContext ()
206+
const Example = (props) => {
207+
// ... Omitted
208+
const {initialized, data} = useFetchData()
209+
if (!initialized) return null
210+
return (
211+
<Context.Provider value={{value: 'any'}}>
212+
{/* ...Assuming a vast of <AnotherFieldNoDependsOnContext /> */}
213+
<Field
214+
innerHooks={() => {
215+
const {value} = useContext(Context)
216+
return {
217+
value,
218+
}
219+
}}
220+
/>
221+
{/* ...Assuming a vast of <AnotherFieldNoDependsOnContext /> */}
222+
</Context.Provider>
223+
)
224+
```
225+
226+
This can limit context scope and are easier to know and extract loosely-coupled component compared to followed by the context example, we could just only use provider in the past, and it's easy to miss how many we set curly braces for deep nests.
227+
228+
```tsx
229+
const Context = createContext ()
230+
const Example = (props) => {
231+
// ... Omitted
232+
const {initialized, data} = useFetchData()
233+
if (!initialized) return null
234+
return (
235+
<Context.Provider value={{value: 'any'}}>
236+
<Context.Consumer>
237+
{
238+
({value}) => {
239+
return (
240+
<>
241+
{/* ...Assuming a vast of <AnotherFieldNoDependsOnContext /> */}
242+
<Field
243+
innerHooks={() => {
244+
const {value} = useContext(Context)
245+
return {
246+
value,
247+
}
248+
}}
249+
/>
250+
{/* ...Assuming a vast of <AnotherFieldNoDependsOnContext /> */}
251+
</>
252+
)
253+
}
254+
}
255+
</Context.Consumer>
256+
</Context.Provider>
257+
)
258+
```
259+
260+
There is simular problem about readability even if you use consumer per components.
261+
262+
# Detailed design
263+
264+
The innerHooks is called in intermediate layer from parent and child.
265+
React render function create component only call hooks and merge props passed by innerProps.
266+
267+
```tsx
268+
function InterMediate(props) {
269+
const propsFromInnerHooks = innerHooks && innerHooks()
270+
return <Child {...props} {...propsFromInnerHooks}>
271+
}
272+
```
273+
274+
In api level, we may be able to optimize performance.
275+
276+
```tsx
277+
React.createElement(Hello, { innerHooks: someHandleHookFunction }, null);
278+
279+
function createElement(Component, props, ...children) {
280+
if (props.innerHooks) {
281+
props = merge(props, props.innerHooks());
282+
}
283+
// continue to original function process
284+
}
285+
```
286+
287+
# Drawbacks
288+
289+
- possible to be worse rendering performance by intermediate hooks
290+
- incliding parent scope variables in innerHooks can perfome unexpected side effects.
291+
- type inference is more complicated, it needs returned type of innerHooks and exclude them from original props if it injected
292+
293+
# Alternatives
294+
295+
No idea.
296+
297+
# Adoption strategy
298+
299+
- This does not have any breaking changes. It can ignore if there is not an innerHooks prop, unless users name a prop innerHooks.
300+
- React typing library like flow and typescript should change component type so that infer props type when exists the innerHooks prop.
301+
302+
# How we teach this
303+
304+
The terminology is innerHooks.
305+
306+
We may need only adding innerHooks usage the React Hooks entry of document.
307+
308+
And introduction as new feature is enough.
309+
310+
# Unresolved questions
311+
312+
- How to imprement innerHooks during rendering.
313+
- I may not consider enough how extent innerHooks side effects by innerHooks of decendants from parent have bad effects.

0 commit comments

Comments
 (0)