Summary
The core replacement engine (Monkey.js) contains hardcoded AppDynamics-specific corner cases. These should be isolated behind a plugin or namespace hook so vendor-specific behavior is extensible without modifying the core engine.
Problem
AppDynamics-specific logic (special DOM handling, namespace commands in src/commands/appdynamics/) is woven into the core engine. This makes the engine harder to understand and couples it to one vendor's UI patterns.
Suggested approach
- Define a plugin interface that namespaced command sets can implement (e.g.,
beforeApply, afterApply, custom DOM walkers)
- Move AppDynamics-specific branches in
Monkey.js behind this interface
- Register the
appdynamics namespace as the first plugin
- Ensure existing
@namespace[] = appdynamics configs continue to work unchanged
Risks
- Must preserve backward compatibility with existing configurations
- Performance impact of plugin dispatch in the hot loop needs measurement
Summary
The core replacement engine (
Monkey.js) contains hardcoded AppDynamics-specific corner cases. These should be isolated behind a plugin or namespace hook so vendor-specific behavior is extensible without modifying the core engine.Problem
AppDynamics-specific logic (special DOM handling, namespace commands in
src/commands/appdynamics/) is woven into the core engine. This makes the engine harder to understand and couples it to one vendor's UI patterns.Suggested approach
beforeApply,afterApply, custom DOM walkers)Monkey.jsbehind this interfaceappdynamicsnamespace as the first plugin@namespace[] = appdynamicsconfigs continue to work unchangedRisks