Skip to content

Adapters and Fluxer compatibility

Adapters connect generic runtime services to Fluxer’s interface. Keep this boundary separate from both installation compatibility checks and plugin-specific feature logic.

FluxerAdapter identifies supported documents and supplies client-info injection, composer attachment actions, the settings surface, and optional posted-file context actions.

Core supplies generic callbacks and data. Adapters handle the DOM structure needed to attach those features and return cleanup functions.

When upstream structure changes, reproduce the relevant surface with a controlled DOM fixture. Verify action placement, submenu ownership, focus behavior, rerender survival, and cleanup.

Avoid broad selectors that capture unrelated controls. Ensure a missing surface fails gracefully without repeatedly creating orphaned nodes.

A structurally compatible app archive can still have changed UI markup. Installation detection and DOM adaptation need separate evidence.

Neko sprite selectors and inspection presentation belong in their plugin. Adding a new plugin selector is not a reason to create a feature-specific runtime API.

Named hooks expose serialized values rather than arbitrary function replacement. The current client-info.lines hook is one example.

Run adapter tests and pnpm test:architecture for integration changes; use Electron fixtures when the change affects full runtime startup or menu behavior.