News for hackers. Stuff that matters.
Re:React best practices by skaushik92 on Monday May 03, 2021 @05:52PM (#27031228)
The crux of the problem here is overgeneralization to the point of losing meaning and scope.

The most blatant signal for this is the else case here. The else case literally calls one of the props with on of its other props passed in. You could easily ask the question "Why couldn't the consumer of this component just do that instead?"β€”in this else case the Action component loses meaning by breaking the single responsibility principle. It becomes so overgeneralized that literally any component could be rendered through it.

Re:React best practices by dcherman on Monday May 03, 2021 @05:55PM (#27031273)
Agreed, was typing a similar comment, however yours expressed that idea better than mine.

Consider that this pattern contains N different properties that renders N different components (plus the default case), I don't know why you would want to put this into one component rather than having the consumer select the right one themselves. This even introduces the possibility of bugs - what happens if a consumer passes two sets of properties (which admittedly could be somewhat prevented by Typescript)? I don't really see the benefits of this approach for this particular example.

Re:React best practices by wnevets on Monday May 03, 2021 @05:59PM (#27031335)
It feels like this is a general problem with the entire React ecosystem.
Re:React best practices by ZephyrBlu on Monday May 03, 2021 @06:07PM (#27031425)
I think the benefit of a component like this is that it is a well defined interface. As long as it doesn't become a monster super-component then it seems useful.