3 ms·
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 c
by skaushik92 5y ago
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.
- dcherman 5y agoAgreed, 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.
- wnevets 5y agoIt feels like this is a general problem with the entire React ecosystem.
- ZephyrBlu 5y agoI 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.