I agree the proposal about the separation of concerns for React. Even today, it is still worth discussing~
I use React and Vue in my daily development, but I prefer React. Recently, I'm also studying how to separate concerns of React function components. According to my own development habits to talk about my point:
Reusability of custom hooks
I think that if there is a lot of logic code in the function component, it is necessary try to extract custom hooks, which is helpful to the visual isolation effect of the code;
But at the same time, I don't agree that some logic without reusability and less code should be extracted as custom hooks. Because sometimes the complete component code will look like a pile of fragments, and also needs development time to extract custom hooks. If you use typescript, you also need to design a separate type definition for the parameters of hooks. This kind of unnecessary abstraction sometimes affects the development efficiency.
About separate files
I agree with the separation concerns, but I don't agree that the separation of files is necessary.
If a lot of files are separated, some people will have unnecessary mental burden in the continuous file switching operation. For example, in the vscode IDE, a large number of code files with similar names may be opened at the same time, and we often need to spend the cost of sorting out the relationship between these files in our mind.
So I prefer the implementation SFC of Vue: the components look highly cohesive in one file, but the concerns are still very clearly separated.
As a person who has used both React and Vue, I use TypeScript to developed a
full typings similar SFC solution in JSX/TSX environment for React function components 🤪. It is similar to the setup function of Vue3 in that it achieves separation of concerns in a natural way, and production ready: github.com/joe-sky/jsx-sfc.
I don't think separation of concerns is definitely against React design philosophy. If we can improve the development efficiency and maintainability, it is worth exploring and practicing.
I'd say that personally, I'm not as much after the separation of concerns itself, rather than just making my code cleaner and more maintainable. Separation of concerns is just one of many ways to achieve that.
It's interesting that you've brought up Vue 3, as it recently became my go-to UI framework. I love it but not because of the separation of concerns and SFCs, but actually the complete opposite!
I came to love the setup() method and the Composition API. To me, they're like React Hooks, which I really like, but better. The reactivity model and one-time setup() execution seem much more pleasant to work with for me. On top of that, better JSX and TypeScript support led me to not that good of separation of concerns, but much better development experience and efficiency, combined with clean and maintainable code.
If you're interested in this topic, I wrote more about it here:
Thank you for your reply, I will also read your Vue post. Seriously, I've also consider of the custom hooks idea for the main points of this post.
My situation here is that most projects use React, and I am also a loyal React user. Vue3 is very good now, but JSX/TSX support is not as rich as react ecosystem. For example, there is no stable CSS-in-JS solution(e.g. styled-components、Emotion) for Vue3.
The React SFC inspiration is actually to solve my pain points in the development, I haven't promoted it yet and I'm not sure how many people will agree with it. Separation of concerns is really just a way, but it is very successful in Vue. In the React environment I want to combine the separation of concerns with the existing TSX/eslint/CSS-in-JS ecosystem in a new cohesive way, and no string template is required.
If you take a closer look, you will find that I am not completely imitating Vue's SFC. Of course, different people have different needs, so their understanding will be different, it's perfectly normal.
I did take a look at your library. The API seems interesting, though I can imagine your potential users would really have to know what they're after in terms of structuring their code.
As for Vue 3 - you're right that the ecosystem is lacking. I get around that in my projects as I recently stopped using CSS-in-JS in favor of Tailwind. And although there are a few pain-points, it's a fairly good solution. But I acknowledge that React ecosystem has better tooling available even for Tailwind, which you can in this blog post (another plug 😅):
I agree the proposal about the separation of concerns for React. Even today, it is still worth discussing~
I use React and Vue in my daily development, but I prefer React. Recently, I'm also studying how to separate concerns of React function components. According to my own development habits to talk about my point:
Reusability of custom hooks
I think that if there is a lot of logic code in the function component, it is necessary try to extract custom hooks, which is helpful to the visual isolation effect of the code;
But at the same time, I don't agree that some logic without reusability and less code should be extracted as custom hooks. Because sometimes the complete component code will look like a pile of fragments, and also needs development time to extract custom hooks. If you use typescript, you also need to design a separate type definition for the parameters of hooks. This kind of unnecessary abstraction sometimes affects the development efficiency.
About separate files
I agree with the separation concerns, but I don't agree that the separation of files is necessary.
If a lot of files are separated, some people will have unnecessary mental burden in the continuous file switching operation. For example, in the vscode IDE, a large number of code files with similar names may be opened at the same time, and we often need to spend the cost of sorting out the relationship between these files in our mind.
So I prefer the implementation SFC of Vue: the components look highly cohesive in one file, but the concerns are still very clearly separated.
As a person who has used both React and Vue, I use TypeScript to developed a
full typings similar SFC solution in JSX/TSX environment for React function components 🤪. It is similar to the setup function of Vue3 in that it achieves separation of concerns in a natural way, and production ready:
github.com/joe-sky/jsx-sfc.
I don't think separation of concerns is definitely against React design philosophy. If we can improve the development efficiency and maintainability, it is worth exploring and practicing.
I'd say that personally, I'm not as much after the separation of concerns itself, rather than just making my code cleaner and more maintainable. Separation of concerns is just one of many ways to achieve that.
It's interesting that you've brought up Vue 3, as it recently became my go-to UI framework. I love it but not because of the separation of concerns and SFCs, but actually the complete opposite!
I came to love the
setup()method and the Composition API. To me, they're like React Hooks, which I really like, but better. The reactivity model and one-timesetup()execution seem much more pleasant to work with for me. On top of that, better JSX and TypeScript support led me to not that good of separation of concerns, but much better development experience and efficiency, combined with clean and maintainable code.If you're interested in this topic, I wrote more about it here:
Vue with TSX - the perfect duo!?
Arek Nawo ・ Mar 2 ・ 8 min read
Thank you for your reply, I will also read your Vue post. Seriously, I've also consider of the custom hooks idea for the main points of this post.
My situation here is that most projects use React, and I am also a loyal React user. Vue3 is very good now, but JSX/TSX support is not as rich as react ecosystem. For example, there is no stable CSS-in-JS solution(e.g. styled-components、Emotion) for Vue3.
The React SFC inspiration is actually to solve my pain points in the development, I haven't promoted it yet and I'm not sure how many people will agree with it. Separation of concerns is really just a way, but it is very successful in Vue. In the React environment I want to combine the separation of concerns with the existing TSX/eslint/CSS-in-JS ecosystem in a new cohesive way, and no string template is required.
If you take a closer look, you will find that I am not completely imitating Vue's SFC. Of course, different people have different needs, so their understanding will be different, it's perfectly normal.
I did take a look at your library. The API seems interesting, though I can imagine your potential users would really have to know what they're after in terms of structuring their code.
As for Vue 3 - you're right that the ecosystem is lacking. I get around that in my projects as I recently stopped using CSS-in-JS in favor of Tailwind. And although there are a few pain-points, it's a fairly good solution. But I acknowledge that React ecosystem has better tooling available even for Tailwind, which you can in this blog post (another plug 😅):
Tailwind JSX and class composition
Arek Nawo ・ Mar 3 ・ 8 min read