Extending Nebula

Nebula is extended the Magento way, through DI, plugins, layout XML and templates, plus one thing Magento does not have: JSON overlays. This section is the map of every seam.

Page	What it covers
Extension points	Every registry, interface and event a module can bind to, each with a working example
CSS and JavaScript in your module	How to style and script an admin screen that runs under Nebula
Third-party extensions	What keeps working for an extension you already run, how to check one, and what to do when it does not fit
Generators	Scaffolding a CRUD module, a grid, a form, or converting UI Component XML

The rule every seam follows

Adding a field type, a column type, a data source, a save behaviour, an option source, or a grid should take one adapter class bound in di.xml and one definition. It should never require editing a switch inside the engine. If you find yourself copying a Nebula module to change one thing, there is a seam you have not found; check the Extension points page.

The three ways to change a screen

You want to	Do this	Page
Add, change or remove a column, field, section, button or action on a shipped screen	Ship a JSON overlay with the same id	Grids, Forms
Render a custom panel or cell	Ship a snippet with a template and a view model	Snippets
Add a whole screen	Ship a definition, a layout handle, a controller and a provider	Your first grid, Your first form

Stability

Public contracts live under Api\V1 in each module and are marked @api. A breaking change ships as V2 beside V1 rather than as a new major version of the package. Classes outside Api may change between releases; bind to interfaces where one exists.