My point was that the article did not convince me to use the listed approach. Going further, I do not recommend it at all, because the extra switch abstraction is pointless, makes code less readable and error-prone in a long run.
I'd argue that the logic of what to do with a specific type of order ("Pizza", "Cheeseburger" and "Ice Cream") shouldn't be the responsibility of the React component. It should be refactored outside of the component so that the component can pass some kind of metadata (the name such as "Pizza" etc) to the part of the system actually responsible for acting based on the business requirements (business logic).
If you want to go a step further into actually implementation details of the above example I'd say that reducers may be a good choice here so that the component dispatches an event and delegates the responsibility of acting upon that event (placing an order) to the reducer.
But... I'd also argue that this is an example and there are always more suitable solutions but which may not bring across the knowledge the way the author meant to.
In the example used I believe that the functions were kept in the same component and invoked the way they are based on a conditional to keep it small and digestible without scrolling from one example to the other to understand the relation between them.
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.
My point was that the article did not convince me to use the listed approach. Going further, I do not recommend it at all, because the extra switch abstraction is pointless, makes code less readable and error-prone in a long run.
I'd argue that the logic of what to do with a specific type of order ("Pizza", "Cheeseburger" and "Ice Cream") shouldn't be the responsibility of the React component. It should be refactored outside of the component so that the component can pass some kind of metadata (the name such as "Pizza" etc) to the part of the system actually responsible for acting based on the business requirements (business logic).
If you want to go a step further into actually implementation details of the above example I'd say that reducers may be a good choice here so that the component dispatches an event and delegates the responsibility of acting upon that event (placing an order) to the reducer.
But... I'd also argue that this is an example and there are always more suitable solutions but which may not bring across the knowledge the way the author meant to.
In the example used I believe that the functions were kept in the same component and invoked the way they are based on a conditional to keep it small and digestible without scrolling from one example to the other to understand the relation between them.