|
|
|
|
|
|
by underwater
2616 days ago
|
|
|
That feels a bit strange as a design philosophy; the point of components is that they encapsulate implementation and offer a simple, unambigious interface for configuration. If someone needs a component to do something it doesn't do, that's a sign that the primitives are wrong and the component needs to be refactored. Punting the solution back to product teams is prioritising short terms wins at the expense of long term pain. Imagine if we extended this philosophy to other paradigms: every method and property on a class is public and overridable, just in case we need to change the behaviour. |
|
|
A concrete example probably does a better job of explaining how this is used: https://medium.com/@dschnr/better-reusable-react-components-...
Referring to the Uber Freight RadioGroup and Tag Edit overrides from that article (not my article to be clear), those are cases where the vast majority of functionality from the original components satisfied the usage requirements, but a small tweak was needed to get the desired outcome. The override pattern is simply a way of building flexibility into the components and acknowledging that the users of the components may want to change them in ways that were not obvious to the component author. Those two examples may be fairly straightforward, but at what point do you stop with exposing the ability to change things? In our prior component library we saw a number of cases where teams wanted the ability to customize things that were more subtle, ie- changing the html element type on a subcomponent for a very specific purpose. This pattern came from observing the usage of our prior internal component library and talking with many of the internal consumers. It's probably not be a fit for everyone, but it works well for us.