A developer often needs to change an existing Odoo front-end component, not build a new one. Patching is a means of extending it. This piece is about it.
The need to change an existing component
Much Odoo development changes existing things rather than building new ones, and that holds on the front end as well as the back end. A developer often needs an existing Odoo front-end component, something Odoo already provides, to be changed: its behaviour adjusted, something added. The question is how to make that change, and the answer is, once again, the central principle of clean Odoo development: extend, do not replace.
Patching as a way of extending
Patching, in the Odoo front-end context, is a means of extending an existing component: applying a change to it, extending or adjusting its behaviour, rather than replacing the component wholly. Through patching, a developer can change an existing component's behaviour while the component otherwise remains as it is. Patching is, in essence, the front-end means of extending an existing component, the counterpart, on the front end, to the inheritance that extends back-end models and views.
Why extending beats replacing
Extending an existing component, rather than replacing it, is the clean way, for the same reasons that extending is clean throughout Odoo. Extending applies just the genuine change, leaving the existing component, perhaps Odoo's own, otherwise intact, so the change is a clean, identifiable layer. This is maintainable, and it carries through upgrades far better: when Odoo's component changes in a new version, an extension that applied just the genuine change adapts far more readily than a wholly replaced component would. Replacing an existing component wholly, by contrast, substitutes the developer's whole version for Odoo's, which is fragile and a burden at upgrade. Extending through patching is the clean way; replacing is not.
Patching deserves care
An honest note. Patching changes the behaviour of an existing component, and it should be done with care: the change should be the genuine, intended change, applied so it extends the component cleanly without breaking what should still work. Patching done carelessly could disrupt the existing component's genuine behaviour. A developer extending a component with patch should make the genuine, intended change, cleanly, and ensure the component's genuine behaviour, beyond the change, still works. Patching is a means of extending, and extending should be done so it genuinely extends, not breaks.
The takeaway
Extending an Odoo component with patch is the front-end means of changing an existing component by extending it rather than replacing it. Patching applies a genuine change to an existing component, extending or adjusting its behaviour while the component otherwise remains intact, the front-end counterpart to the inheritance that extends back-end models and views. Extending through patching is the clean way, maintainable and far better through upgrades than replacing the component wholly. Patching deserves care, so the change extends cleanly without breaking what should still work. For how we approach Odoo, see our ERP practice.