Custom Frontend Components

[rvveber]

Proposal: Introducing a Flexible Plugin System

Why now? There is currently no plugin mechanism in the codebase. This proposal introduces one, driven by real‑world requirements from our openDesk production deployments (white‑label/government Kubernetes instances that must integrate seamlessly into their existing digital suites).

---

Goals

1. Custom Functionality Without Forking – Enable openDesk and other whitelabel instances to add or swap features without shipping a custom container image of the entire application.
2. Protect Core Velocity – Keep the main repository lean; extensibility must not complicate the upstream codebase.
3. Positioning Power – Allow plugins to be injected before / after / prepend / append / replace any matching DOM node so integrators can position, augment, or even fully replace existing UI components.
4. Predictable Governance – This is not intended as a free‑for‑all community marketplace. Each instance decides which plugins it loads, preserving security, branding and user‑experience guarantees.

---

Proof‑of‑Concept (Module Federation)

I invested engineering time to build a working POC that demonstrates:

• Dynamic runtime loading of remote modules listed in a simple plugins.json file (no rebuild required).
• Bi‑directional sharing of React components, context, and state between host ↔ plugin.
• Selector‑based injection so the instance configuration chooses where each plugin renders.

Repo: https://github.com/rvveber/react-dynamic-bi-directional-module-federation-poc

Run locally (single copy‑paste):

git clone https://github.com/rvveber/react-dynamic-bi-directional-module-federation-poc
cd react-dynamic-bi-directional-module-federation-poc
./demo.sh

Once you open http://localhost:3001 you can see the demonstration.

---

How This Differs from Classic Slot‑Based Systems

Classic Slots	Proposed Selector‑Injection
Fixed "slot" components hard‑wired into the code	Any element matching a CSS selector can act as an anchor
Core devs must anticipate every slot	Core remains agnostic; DOM structure is the contract
Refactors often break plugins	As long as selectors stay stable, refactors are safe

---

FAQ & Open Questions

• Security / isolation?
  Remote entries are loaded only from whitelisted origins; each deployment controls its allow‑list.

• Version skew?
  Module Federation shares singletons (React, react‑query, etc.) to avoid duplicate bundles.

• Performance impact?
  Plugins load after DOMContentLoaded and are cached independently, so cold‑start cost is minimal.

---

Call for Feedback

Please share your opinions, concerns, and questions. I'm happy to iterate on the POC, update documentation, and drive the initial integration PR once we agree on direction.

Looking forward to the discussion!

[AntoLC]

Seems nice!
Would it be lot of work to do a simple POC in Docs ?