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
OrderReport
that would be children.We could implement
FastOrder
as a standard component that usesOrderReport
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 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
FastTrackingInfo
andSpecialReportInfo
, and then use them in the-Order
components, i.e.Depending on the context of the feature I might also want to rethink the whole thing. But the above would work.