Metadata
- Source
- FLUID-6367
- Type
- Bug
- Priority
- Major
- Status
- Closed
- Resolution
- Fixed
- Assignee
- Colin Clark
- Reporter
- Antranig Basman
- Created
2019-01-28T11:57:13.956-0500 - Updated
2024-07-22T10:35:32.726-0400 - Versions
- N/A
- Fixed Versions
-
- 3.0
- Component
-
- Framework
Description
This problem didn't appear in any "released" version of the framework, but emerged as a hidden expectation by framework users as part of the FLUID-4982 "asynchronous ginger world work" in https://github.com/fluid-project/infusion/pull/824 . In the implementation of the InlineEdit component, there is the following implementation:
fluid.inlineEdit.initializeEditView = function (that, initial) {
if (!that.editInitialized) {
fluid.inlineEdit.renderEditContainer(that, !that.options.lazyEditView || !initial); if (!that.options.lazyEditView || !initial) {
that.events.onCreateEditView.fire(); if (that.textEditButton) {
fluid.inlineEdit.bindEditFinish(that);
}
fluid.inlineEdit.bindBlurHandler(that);
that.editView.refreshView(that);
that.editInitialized = true;
}
}
};
The purpose here to enable lazy initialisation of the edit view in the case where its construction is something very expensive, e.g. a rich text editor. This function may be called both from the component's "onCreate" as well as being triggered by the "edit" operation.
In practice this is a terrible, old-fashioned reliance on long scads of imperative code and conditionals, but whilst we are continuing to build supports for the bridges between imperative and declarative modes of rendering and initialisation, we will have to do our best to support this idiom even though it will require a fair amount of special-casing in the promise sequencing in the new framework's commitPotentiae implementation.
Once "imaged components" and the new renderer are established and mature, we would be able to kick away the special-casing as a result of the reduced expectation of observability of the framework internals at odd workflow points. At this point we would ideally just remove the entire facility for "createOnEvent" components in favour of their model-driven alternatives.