Even though most people's primary interaction with Uber is through the native apps, there's a ton of web applications built here. The opening line of the linked article is: "At Uber, we have hundreds of internal web applications" Additionally, there are a number of customer facing web apps from a web version of the rides app to Uber for Business to Uber Freight.
A big part of the goal with the overrides mechanism was to provide usable components out of the box that could optionally be modified if something needed to be changed for a given use case.
You can use the components as is, using props if you're ok with the out of the box style/functionality/etc, without ever touching overrides. The overrides provide a standardized interface to changing the component internals across the entire component library.
That approach may be overkill for simple components that are trivally composable (Card for example), but is incredibly powerful for a component like Datepicker where you may want to change styles or functionality of a deeply nested component without exposing a massive top level props interface.
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.
I disagree- the default use case is still to use the components without overriding. Having a well defined mechanism for changing the component allows for consumers of the components to still get the main benefits of the component and the owners/maintainers have better visibility into what (if any) changes may need to be made to the core 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.
But you’re still creating a suite of components that can be composed to create a specific instance of a date picker. Except with the override config, you’re now complicating and limiting the simple and versatile concept of composition.
Your components now need to follow some pre established and short sighted rules in order to understand how to manage their own children.
To use the example in the article, lets say you have an Option component, but now you want a version of that component that takes two additional components under certain conditions. E.g, an icon, and a checkbox? But only when one specific Option has a specific combination of props?
How does this override system handle that? It doesn’t. Composition handles that. But if components are created with this override system in mind, they lose the ability to be composed in more complex ways than the designer of the override system imagined.
It turns out I was wrong about this, but not in a good way.
It appears you can pass functions to the config that render components, which presumably can also take an override config which in turn can take a function to render components and so on. So it's basically negating the entire point of JSX. It's halfway between JSX and React.createElement. The worst of both worlds.
https://www.nceo.org/articles/stock-options-alternative-mini... does a decent job explaining it. Essentially, you exercise at the price you were granted the options, but if the value has gone up since then, you're taxed (AMT) on the delta between the exercise price and the current value.
From the article:
"The company, which has raised some $15 billion in equity and debt funding, said it still has $7.2 billion of cash left on hand, about the same as it had at the end of last year."
I made a similar one but instead of waiting 4 seconds, it makes a new request after it sees a new error response: http://pastebin.com/raw.php?i=XWwm8Sdv
If you ever really developed a time machine, you could go back in time and either pay off (with money made from placing bets on events you know the outcome of) or in some other way prevent the original filer from submitting his claim.
