...
One of our own, to round out the set. In order to get our half-baked incarnation of the FLUID-4982 asynchronous ginger world for Infusion 4.x, we special-cased the status of fluid.resourceLoader in the architecture - it's the only site where asynchrony may be resolved during component startup. However, this just creates a Bracha-ist "shadow domain" with respect to this configuration as was encountered when trying to update WeCount's covid-data-monitor project to account for the "latest" fetch idiom required by binding it to the merged data in https://github.com/inclusive-design/covid-assessment-centres/tree/main/merged. ResourceLoader's fixed record structure was designed to be a "one stop shop" for simple cases and so trying to insert any indirection here immediately breaks the user out of the structure they understand and requires them to understand some other primitive. In this case far from a simple one too - my first thought was to produce some form of transforming promise chain by bridging the Resource to a DataSource - but really at this point it is far simpler to break out entirely and write an arbitrary promise-producing structure in code using the "promiseFunc" integration that we produced for ADTKINS. Infusion 6 can't roll on soon enough!
An ireemediably non-integral action
Not a reuse failure as such, but morally seems to belong in this section - an example of a designed interaction which is strongly resistant to the "integral" idiom designed into the "integral bindings" model of the new (Infusion 5.x) renderer. As part of the TextfieldControls components delivered primarily for use in the Infusion preferences framework, there is an interaction surrounding a textfield connected to adjacent numerical controls (sliders or steppers). The validation applied to the textfield in this situation is intended to reject non-numeric inputs. The flow is - when a non-numeric input is received into the textfield, not only is the update to its value rejected, but the most recently valid numeric input (stored in the state in a linked control) is restored into it. This is hard to arrange by integral techniques, since the value held in the control from which the update is received has not been updated - instead, it is the target of the update whose value has changed - but this update is to be reverted. This led to the following very awkward code in the old (Infusion 1.x) implementation, which it was not possible to substantially improve on in Infusion 5.x:
| Code Block |
|---|
fluid.textfield.setModelRestrictToNumbers = function (that, value, path) {
var isNumber = !isNaN(Number(value));
if (isNumber) {
that.applier.change(path, value);
}
// Set the textfield to the latest valid entry.
// This handles both the cases where an invalid entry was provided, as well as cases where a valid number is
// rounded. In the case of rounded numbers this ensures that entering a number that rounds to the current
// set value, doesn't leave the textfield with the unrounded number present.
that.container.val(that.model.value);
}; |
This reaches out into the view layer in order to hoist the value of one control into another.
We could only improve on this marginally by binding the current string value of the textfield into a dedicated string-valued model field - but if we then in addition attempted to react to changes in the texfield control to run the non-integral interaction, we'd run the risk of racing against it.