Metadata
- Source
- FLUID-6738
- Type
- New Feature
- Priority
- Major
- Status
- Pull Request
- Resolution
- N/A
- Assignee
- Antranig Basman
- Reporter
- Antranig Basman
- Created
2022-05-27T06:56:57.411-0400 - Updated
2022-05-27T11:01:40.504-0400 - Versions
-
- 4.0
- Fixed Versions
- N/A
- Component
-
- Framework
Description
The code exhibiting FLUID-6737 was created as a result of what seems to be a recurrent requirement - that multiple "instances" of something be resolvable against a common singleton (conventionally at the root of the tree), where the construction of the singleton should be timed to be "immediately before" the first of the dependent instances.
FLUID-6737 makes use of the "fluid.resolveRootSingle" directive to mount the singleton, expressed as a subcomponent of the client, at the root, but runs into difficulties because each successive instance reconstructs the singleton as its subcomponent.
The Infusion 4.0 "workflow functions", invented to support the "new renderer", should be able to allow this constructional pattern to be expressed in a declarative way.
Comments
-
Antranig Basman commented
2022-05-27T11:01:40.504-0400 A "test balloon" implementation is available in https://github.com/fluid-project/infusion/pull/1082/files# as the grade
fluid.rootMaker
and its accompanying workflow function. Since this is a global workflow function with priority "first", this acts early enough to resolve references from any options material or model relays etc., although there is one usage which is not possible, which is referencing the created singleton from a directly injected subcomponent reference - e.g.fluid.defaults("fluid.tests.fluid6738test", { .... components: { webMidi: "{fluid.tests.fluid6738webMidi}" } });
would not be possible, since the gap between initComponentShell and processComponentShell in FluidIoC.js is not covered by the workflow system. If this implementation ended up being useful, we could consider hoisting processComponentShell into a new initial workflow phase so that we could place the rootMaker before it - although this would end up not discovering any literal subcomponents that wanted to create roots. Possibly we could just hoist the resolution of injected component references into a workflow phase.