Arguments to listeners are expanded eagerly, inconsistent with strategy for invoker arguments
Description
Arguments to listeners are expanded by a custom workflow leading from fluid.instantiateEvents -> fluid.mergeListeners -> fluid.event.resolveListenerRecord using the old-fashioned heavyweight "fluid.expandOptions"" rather than the more modern "fluid.preExpandOptions" seen in fluid.makeInvoker:
This implies that any volatile references, e.g. to model material will likely cause a workflow failure. We encountered this when writing a dataSource transforming event listener as
which ended up forcing model evaluation far too early, as part of the pseudo-workflow stage 0 attached to "fluid.instantiateEvents" in the transitional framework.
What will this look like in the future? Probably not vastly different - we will still likely have some kind of monomorphisation site attached to these resolution sites, only we will at least have somewhere sensible to cache their results as part of the immutable tree. There will still be "workflow stages" only these will be scheduled as ticks rather than as promise tangles.
Analogous issues are FLUID-6373, noting that the "func" member of listeners/invokers is always evaluated early, and FLUID-6405 noting that the evaluation of "listener" members of IoC testing framework blocks is always eager.
Arguments to listeners are expanded by a custom workflow leading from fluid.instantiateEvents -> fluid.mergeListeners -> fluid.event.resolveListenerRecord using the old-fashioned heavyweight "fluid.expandOptions"" rather than the more modern "fluid.preExpandOptions" seen in fluid.makeInvoker:
This implies that any volatile references, e.g. to model material will likely cause a workflow failure. We encountered this when writing a dataSource transforming event listener as
which ended up forcing model evaluation far too early, as part of the pseudo-workflow stage 0 attached to "fluid.instantiateEvents" in the transitional framework.
What will this look like in the future? Probably not vastly different - we will still likely have some kind of monomorphisation site attached to these resolution sites, only we will at least have somewhere sensible to cache their results as part of the immutable tree. There will still be "workflow stages" only these will be scheduled as ticks rather than as promise tangles.
Analogous issues are FLUID-6373, noting that the "func" member of listeners/invokers is always evaluated early, and FLUID-6405 noting that the evaluation of "listener" members of IoC testing framework blocks is always eager.