This is exactly counter to react paradigms (and only sort of "polymorphism").
The "react way" would be to write a Card component that accepts an icon and a className, and then having e.g. a ReactCard that renders Card with preset values for the icon and className. Coupling the Card directly with its supported variants actually hugely limits the reusability and flexibility, and requires that the Card be constantly kept up to date with all possible variants.
Precisely. I've made a few adjustments to make it work on codepen, but the gist is there:
Rather than selecting the variant settings from within the Card, we supply the variant settings to the card. The result is ultimately still that you just call, e.g. <ReactCard /> with your show, headerText, and text props, but now you can easily extend this to support, for instance, an AngularCard without having to touch Card at all:
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.
This is exactly counter to react paradigms (and only sort of "polymorphism").
The "react way" would be to write a
Cardcomponent that accepts an icon and a className, and then having e.g. aReactCardthat rendersCardwith preset values for the icon and className. Coupling theCarddirectly with its supported variants actually hugely limits the reusability and flexibility, and requires that theCardbe constantly kept up to date with all possible variants.Okay so what I'm understanding from this is that
ReactCard.Card, where theCardcomponent accepts an icon and a className. Right?Precisely. I've made a few adjustments to make it work on codepen, but the gist is there:
Rather than selecting the variant settings from within the Card, we supply the variant settings to the card. The result is ultimately still that you just call, e.g.
<ReactCard />with yourshow,headerText, andtextprops, but now you can easily extend this to support, for instance, anAngularCardwithout having to touchCardat all: