I think this approach is more prone to error and breaking hooks rules.
Also, i don't see any benefit in this, the version with custom hooks is more easy and simple to understand.
I'm not saying is invalid React, I'm only saying it's more complex than using React the simple way, and it's not needed.
In the examples made, the code look worst than abstracting using custom hooks or other solution.
It's more difficult to read and understand.
Also innerHooks mean nothing, it's not clear how you have to use it, what should the function return? If someone read this code after one month will not understand why it's done this way and what it's doing whiteout enter the Field component.
Good code must be readable and understandable. This is not.
Yeah agree the example above doesn't make any sense however I would like to see a dom node hook api like I said this makes sense indeed, if you are not familiar with it try the element hooks which Svelte.js has quickly in Codesandbox , they are awesome.
I works at startup in Japan as CTO.I'm using React and React Native mainly with Typescript.I have launched 3 web service and 4 mobile app ever using various technologies.I sometimes contribute OSS
Location
Japan
Education
Advanced Science and Engineering Electrical Engineering and Bioscience of Waseda University
My library written in typescript and type inference works as you won't lose what totally you should return as partial props and rest props from component is validated by inferred rest props and vise versa. The returned value allows only key-value of the partial component props.
I'm on your side about with no abstraction code is very bad for general components (Most of them are presentational), but there are some limited cases you may not come across that build and scrap each condensable components in one component is preferred to courteous declarative or split components. These will need just only container injection in most cases.
Please be tolerant. I don't think your opinion is wrong. Please don't fight anyone for the reason they are different from you to make meaning discussion though it may be needless to say.
I works at startup in Japan as CTO.I'm using React and React Native mainly with Typescript.I have launched 3 web service and 4 mobile app ever using various technologies.I sometimes contribute OSS
Location
Japan
Education
Advanced Science and Engineering Electrical Engineering and Bioscience of Waseda University
this approach is more prone to error and breaking hooks rules
I want you to tell examples if you can.
Ofcourse, I know it looks breaking them, but my suggestion hooks called inside intermediate component, in fact, wrapped effects called are not breaking as long as you use innerHooks correctly in hooks rules.
The rules are rules, so should be changeable if don't match our benefits.
Most useful case of my approach is to wrap context one component. You can do this
This may annoy you because consumer scope can become wide and deep, thus they are possible to become tough to read even if you write them declarative. Consumer is confused about how deep it is or how wide it is . Furthermore, this intend to cause performance problem if you have some wrong to set appropriate scope.When you can't useContext in parent hooks scope because Provider still isn't rendered so, we had only way to Consumer function like an example above ever. There are libraries use Provider component and, you have no choice except to separate components or consumer function above if you don't use innerHooks.
React Admin match this concept. The presentational component is simple from ui-material, but if you want this context, your DX become worse because nonetheless their field components are deeply-coupled you need separate them or have deep nest by consumer.
In addition, React rendering rules should avoid deeper component tree as long as possible, because it's tough to find where the state derived from and as it's closer to parent it can call un-effective render many times. In the perspective of architecture, I think presentational components should become independent, but
don't need state injected components do so. My way can avoid deeper tree if your components are not so complicated.
But, I also learn from your point. I should make it clear that it is useful in some limited situations.
Thank you for opinion!
In this example make no sense to use a context. Context should be use only if data must be shared from components that have a distance > 2 in the hierarchy.
This approach make you use context the wrong way.
I works at startup in Japan as CTO.I'm using React and React Native mainly with Typescript.I have launched 3 web service and 4 mobile app ever using various technologies.I sometimes contribute OSS
Location
Japan
Education
Advanced Science and Engineering Electrical Engineering and Bioscience of Waseda University
Yeah of course I know what you tell.
Normally, context provider should be upper component in tree. This is for explanation.
There are some unique libraries implicitly provide limited scoped context like react-final-form its provider provide all form values via the context and hooks to access the context.
The hooks can't be used before start rendering because the scope is outer provider. So you must use consumer like above if you want to implement all logic to one component, or you'll split it to somewhat many field components with their state hooks. Form is deeply-coupled so split components per state is not so useful. Thus there are some cases to rewrite consumer to innerHooks like above means. In the other words, this is for the users of the libraries like react-admin form or react-final-form. If you use them, you'll understand what I mean. If not so, sorry I couldn't help without saying this may be not for you.
And innerHooks can write in declarative way as I added latest explanation in this article.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think this approach is more prone to error and breaking hooks rules.
Also, i don't see any benefit in this, the version with custom hooks is more easy and simple to understand.
This is totally valid React.
I'm not saying is invalid React, I'm only saying it's more complex than using React the simple way, and it's not needed.
In the examples made, the code look worst than abstracting using custom hooks or other solution.
It's more difficult to read and understand.
Also innerHooks mean nothing, it's not clear how you have to use it, what should the function return? If someone read this code after one month will not understand why it's done this way and what it's doing whiteout enter the Field component.
Good code must be readable and understandable. This is not.
Yeah agree the example above doesn't make any sense however I would like to see a dom node hook api like I said this makes sense indeed, if you are not familiar with it try the element hooks which Svelte.js has quickly in Codesandbox , they are awesome.
My library written in typescript and type inference works as you won't lose what totally you should return as partial props and rest props from component is validated by inferred rest props and vise versa. The returned value allows only key-value of the partial component props.
I'm on your side about with no abstraction code is very bad for general components (Most of them are presentational), but there are some limited cases you may not come across that build and scrap each condensable components in one component is preferred to courteous declarative or split components. These will need just only container injection in most cases.
Please be tolerant. I don't think your opinion is wrong. Please don't fight anyone for the reason they are different from you to make meaning discussion though it may be needless to say.
Intresting.
I want you to tell examples if you can.
Ofcourse, I know it looks breaking them, but my suggestion hooks called inside intermediate component, in fact, wrapped effects called are not breaking as long as you use innerHooks correctly in hooks rules.
The rules are rules, so should be changeable if don't match our benefits.
Most useful case of my approach is to wrap context one component. You can do this
If you want to do without this. Now,
This may annoy you because consumer scope can become wide and deep, thus they are possible to become tough to read even if you write them declarative. Consumer is confused about how deep it is or how wide it is . Furthermore, this intend to cause performance problem if you have some wrong to set appropriate scope.When you can't useContext in parent hooks scope because Provider still isn't rendered so, we had only way to Consumer function like an example above ever. There are libraries use Provider component and, you have no choice except to separate components or consumer function above if you don't use innerHooks.
React Admin match this concept. The presentational component is simple from ui-material, but if you want this context, your DX become worse because nonetheless their field components are deeply-coupled you need separate them or have deep nest by consumer.
In addition, React rendering rules should avoid deeper component tree as long as possible, because it's tough to find where the state derived from and as it's closer to parent it can call un-effective render many times. In the perspective of architecture, I think presentational components should become independent, but
don't need state injected components do so. My way can avoid deeper tree if your components are not so complicated.
But, I also learn from your point. I should make it clear that it is useful in some limited situations.
Thank you for opinion!
In this example make no sense to use a context. Context should be use only if data must be shared from components that have a distance > 2 in the hierarchy.
This approach make you use context the wrong way.
Yeah of course I know what you tell.
Normally, context provider should be upper component in tree. This is for explanation.
There are some unique libraries implicitly provide limited scoped context like react-final-form its provider provide all form values via the context and hooks to access the context.
The hooks can't be used before start rendering because the scope is outer provider. So you must use consumer like above if you want to implement all logic to one component, or you'll split it to somewhat many field components with their state hooks. Form is deeply-coupled so split components per state is not so useful. Thus there are some cases to rewrite consumer to innerHooks like above means. In the other words, this is for the users of the libraries like react-admin form or react-final-form. If you use them, you'll understand what I mean. If not so, sorry I couldn't help without saying this may be not for you.
And innerHooks can write in declarative way as I added latest explanation in this article.