This is generally a rule of thumb, but I think that consistency is an important factor. While splitting every single component adds boilerplate, like you said, it will make sure that you won't have to look in two places ("where is the logic, in the containers or components?") and you won't have to split the component when it starts to grow.
I do like the pattern, but in many cases I'd be inclined to split it later "when I have to". Right now it's as if you're in fact criticizing the design decision of React (and other similar frameworks) to lump presentation and logic together, i.e. you're giving React a "controller and view" architecture after the fact ... but again, I do like the pattern, and especially the way you're coding it - clean, elegant and simple, the only thing I don't know is if I would always do it right off the bat.
I don't think that splitting view and logic into separate files is against React design. It's been said many times that components doesn't have to emit JSX. Angular even encourages you to, having separate .template.html file.
But all this aside, this is strictly an idea. I've been using this approach for quite some time and I found it helpful, but that's me :) Please, let me know with what you'll end up with, perhaps you'll have better idea and we will all win then :)
I agree that it isn't against React design, as you know React is in totally non-opinionated about these kind of things (unlike frameworks like Angular and, to a lesser extent, Vue), that's why these kinds of architectural patterns are so heavily discussed within the React community.
As I said, I do like the idea, I was only questioning the practicality (or necessity) of splitting every component this way. My feeling/intuition is that the pattern is most valuable for the bigger or more complicated components. The principle or the concept as such is totally fine with me.
(I don't really have a better idea, and in the React world as in other "worlds" there are many ways to approach these problems, I'm not claiming to be an expert in this area, far from it)
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.
Hey leob, thank you for your comment.
This is generally a rule of thumb, but I think that consistency is an important factor. While splitting every single component adds boilerplate, like you said, it will make sure that you won't have to look in two places ("where is the logic, in the containers or components?") and you won't have to split the component when it starts to grow.
I do like the pattern, but in many cases I'd be inclined to split it later "when I have to". Right now it's as if you're in fact criticizing the design decision of React (and other similar frameworks) to lump presentation and logic together, i.e. you're giving React a "controller and view" architecture after the fact ... but again, I do like the pattern, and especially the way you're coding it - clean, elegant and simple, the only thing I don't know is if I would always do it right off the bat.
I don't think that splitting view and logic into separate files is against React design. It's been said many times that components doesn't have to emit JSX. Angular even encourages you to, having separate
.template.htmlfile.But all this aside, this is strictly an idea. I've been using this approach for quite some time and I found it helpful, but that's me :) Please, let me know with what you'll end up with, perhaps you'll have better idea and we will all win then :)
I agree that it isn't against React design, as you know React is in totally non-opinionated about these kind of things (unlike frameworks like Angular and, to a lesser extent, Vue), that's why these kinds of architectural patterns are so heavily discussed within the React community.
As I said, I do like the idea, I was only questioning the practicality (or necessity) of splitting every component this way. My feeling/intuition is that the pattern is most valuable for the bigger or more complicated components. The principle or the concept as such is totally fine with me.
(I don't really have a better idea, and in the React world as in other "worlds" there are many ways to approach these problems, I'm not claiming to be an expert in this area, far from it)