Piral Plugins
A PiralPlugin is a factory function that adds methods to the Pilet API for all pilets. It is the primary extension mechanism for app shell authors.
setup and uses it as the glue — all interaction with the shell and the wider application flows through it.What plugins are for
Plugins live only in the app shell — a pilet never installs or references one. A plugin has exactly one job: to extend the Pilet API. That is the entire reason any plugin exists. When the app shell registers a plugin, the methods it returns are merged into the api object every pilet receives in setup.
This is worth stressing, because it is a common misconception: a plugin is not what makes a feature work. The underlying capability — fetching data, authenticating, talking to a backend — works with or without a plugin. The plugin merely exposes a convenient, typed entry point for that capability on the Pilet API.
piral-oidc is a good example. It exists to surface OIDC concerns — access tokens, the current user, sign-in and sign-out — to pilets through the API (for instance api.getAccessToken()). You do not need it to use OIDC, or to have authentication at all: the app shell can authenticate however it likes and never install the plugin. You add piral-oidc only when you want pilets to consume those tokens through the Pilet API. The same is true of every official plugin — each one is purely a typed extension of the API surface.
Type signature
Three layers:
- Outer function — receives the global state context (for reading/writing app state)
- Inner function — called once per pilet at load time, receives the base API and pilet metadata
- Return value — the methods merged into the pilet's
apiobject
Typed plugin example
Register in the shell:
All pilets now have api.trackEvent('button-click') — typed.