It is not a good idea to use the abstract class as a type of injectable stratagy. It is better to define the interface. More than, this interface must be defined on the statagy application side, not on the implementation side (see DIP).
Another problem I see is that we are trying to use a design pattern for issue that must be solved in another way.
If we are talking about different cuntries and currencies, it seems we need to talk about a different languages.
So, it means all story related to the amount formatting, discount messages, and even static text inside of the PricingCard and its sub-components are matter of localezation.
So, it is better not to invent a weel, but use old, kind i18.
That means that the final interface of the PricingCard must looks like that:
exporttypePricingCardProps={price:number;discount:number;currency:string;// could CurrencyEnum or something like thatcountryCode:string;// or number, or CountryEnum}constPricingCard:React.FC<PricingCardProps>;
And all the rest doing with i18next-react (or something similar).
We had text generation logic out of the view, and we got a problem when we met a need to support several languages -- so, it is better to keep all text as much close to be replaced with {t('MESSAGE')} as it is possible from the project beginning.
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, @itswillt
It is not a good idea to use the abstract class as a type of injectable stratagy. It is better to define the interface. More than, this interface must be defined on the statagy application side, not on the implementation side (see DIP).
Another problem I see is that we are trying to use a design pattern for issue that must be solved in another way.
If we are talking about different cuntries and currencies, it seems we need to talk about a different languages.
So, it means all story related to the amount formatting, discount messages, and even static text inside of the
PricingCardand its sub-components are matter of localezation.So, it is better not to invent a weel, but use old, kind
i18.That means that the final interface of the
PricingCardmust looks like that:And all the rest doing with
i18next-react(or something similar).We had text generation logic out of the view, and we got a problem when we met a need to support several languages -- so, it is better to keep all text as much close to be replaced with
{t('MESSAGE')}as it is possible from the project beginning.