Detour/Abduct

[ng-druid]

The detour module will provide the resources needed to respond to user interactions within panel pages. For example, when user clicks a button carry out an action like saving form data or opening a dialog. Detour will monitor interactions and match them to handlers.

Detour will contain plugin and manage pipeline. Detour will not be knowledgeable of panels.

Abduct will wire panel pages up with detour. This module will be aware of panels.

https://github.com/rollthecloudinc/druid/issues/189

[ng-druid]

The known outcomes

• form submit
  • form name
• Dialog open
  • content?
  • Input Params?
• Navigate
  • route or external
• State change
  • path and value - both as params?

Known Action:

• Browser Interaction
• State Change
  • trigger handler - like snackbar, spinner

[ng-druid]

detour plugins:

• Interaction action
• Interaction event - I don't think we necessarily need this as a plugin. At least not to start. It can just be a static list of all known events. Keep it simple? Maybe match event for element type, if possible determined by match in query selector.
• Interaction outcome (handler) - (event: any, params: Array): Observable -> InteractionOutcomeResult

action describes the event taking place. For example, click event on specific element matched using query selector.

Handler describes the function to be executed as a param compatible wrapped plugin.

A grouping of these plugins is referred to as a listener. To prevent things from becoming to complicated a listeners will enforce a one to one relationship with each plugin implementation inside the interactions editor.

[ng-druid]

The name of the default interaction action will be DomInteractionAction. This will have a type as a string and target. The target will be query selector using a css string.

event triggers handler

We could just delegate all plug-in settings to params. Plugin has option of enforcing object integrity or not. Nstead of params string being controllable by user it would be pre populated based on plugin.

pier of the platform is the elasicicity. Storing config as params seems like a natural step.

• params-config-form (with overload - add)
• params-querystring-form (query string input to build params)

Listener contains:

• event

  • plugin
  • settings (attributes)
  • InteractionDomEvent
    • type = click
    • target = .hello-world

• handler

  • plugin = [ FormSubmit | DialogOpen ]
  • settings
  • paramsString = params string
  • params = Array of Param

[ng-druid]

Builders can add interactions to a panel page. However, they don’t do anything yet. Also, vertigo panel page model needs update to include interactions.

[ng-druid]

Dom events could be registered at the root. Create service named event wire that will wire up events. However, this architecture doesn’t support other variations like pane isolated event observability.

[ng-druid]

I think it’s the events responsibility to wire itself and also call the handler. How to run cleanup once an event is no longer needed like the case is someone changing the page.

[ng-druid]

The event closure could return a BehaviorSubject. In that case the event wouldn’t need to be aware of the handler. Outside code could call the handler instead.

[ng-druid]

The abduct module will house panel page specific event and handlers. The handlers currently inside render will be moved into abduct instead.

[ng-druid]

Thinking this over I don't find it necessary to implement a generic, high level strategy for wiring up interactions for non panel pages. Instead the focus should be building the wiring for panel pages. This will be handled much like sheath where panel page interactions are passed down the panel page component hierarchy being reduced as they match the target based on ancestory. Panel page events will require ancestory targets unless the event belongs to the root page. When a match is made to a panel page, panel, pane the interaction will be wired. The wiring will be delegated to a separate service either part of panels module or inside a new module named abduct. My first thought is to place the wiring service inside panels since that is where mostly all the shared panel specific services have been going anyway. I don't think it makes much sense to break that pattern.

The wiring target could be many things but the most obvious would be the root DOM node of the component. Other possible targets could be the component, layout, etc. inside the component. These seem reasonable but no specific scenario comes to mind at the moment. Although we could implement all lifecycle events and allow builders to add handlers for specific lifecycle events. That might be useful. Perhaps even take it further and make before and after lifecycle events for components.

The event closure will be passed an object that will for now have the root element. In the future new arguments can be added to accommodate differing targets like those below. As a MVP though the root el is probably enough to lead use to the desired functionality for interactions.

Event Targets:

• Root Element (dom node)
• Component
  • outputs (triggers)
  • inputs (changes)
  • lifecycle events
• Child Components
  • outputs? (triggers)
  • inputs? (changes)

[ng-druid]

This branch was somewhat muddied with multiple issues.

• Creating detrour module
  • This has been added to editor not wired up with front-end yet.
• Tailwind Integration
  • Default set-up with extra webpack config
  • Reading files in objects assets for tail wind styles ie. panels with snippets using tail-wind classes
• Fix sheath classify refining algorithm to identify css selector path from DOM nodes with class changes.

[ng-druid]

This issue is going to be closed since the first part is complete. The second part of integrating interactions with the panel page render process will be a separate issue.