Awesome. I love to see how classic principles/best practices are applied in new contexts. Thanks!
Point that I find the most important here is that instead of making component more complex, we can make it more extensible and use it as a building block for other components. Each of them will have a single responsibility and avoid the noise you mention.
The way to do that is not necessarily through higher order components though. It's simpler to create a "hole" in a component by introducing a prop by which we pass nodes. In OrderReport that would be children.
We could implement FastOrder as a standard component that uses OrderReport and extends it with some extras:
We can repeat this process for the next two components, much like you did, but without burdening ourselves with the concept of higher order components.
Also, what I would do at this point is to make OrderReport a component that's only used to build other components (kinda like an abstract class). Then we would have
What I like about this is that it reveals how versatile of a building block components are. Much like functions. And I don't think this relationship is an accident: blog.ploeh.dk/2014/03/10/solid-the...!
@Wiktor Czajkowski those were some great suggestions. I really appreciate the feedback. I love that pattern you are using to get rid of the HOC. It is always amazing to learn something. Thanks a lot :) :)
Awesome. I love to see how classic principles/best practices are applied in new contexts. Thanks!
Point that I find the most important here is that instead of making component more complex, we can make it more extensible and use it as a building block for other components. Each of them will have a single responsibility and avoid the noise you mention.
The way to do that is not necessarily through higher order components though. It's simpler to create a "hole" in a component by introducing a prop by which we pass nodes. In
OrderReportthat would be children.We could implement
FastOrderas a standard component that usesOrderReportand extends it with some extras:We can repeat this process for the next two components, much like you did, but without burdening ourselves with the concept of higher order components.
Also, what I would do at this point is to make
OrderReporta component that's only used to build other components (kinda like an abstract class). Then we would haveShould the requirements only for the basic order change, we can amend
SimpleOrderReport, which doesn't affect the other components!What I like about this is that it reveals how versatile of a building block components are. Much like functions. And I don't think this relationship is an accident: blog.ploeh.dk/2014/03/10/solid-the...!
@Wiktor Czajkowski those were some great suggestions. I really appreciate the feedback. I love that pattern you are using to get rid of the HOC. It is always amazing to learn something. Thanks a lot :) :)
Nice, but how would you handle the case when you have same day and special order report?
Hi. I'd create separate components, like
FastTrackingInfoandSpecialReportInfo, and then use them in the-Ordercomponents, i.e.Depending on the context of the feature I might also want to rethink the whole thing. But the above would work.