The module configuration is a thin wrapper around the PersistentData
provided by the developer into the module's namespace.
It is automatically generated when using the Flux decorator.
Once instantiated, the ModuleConfiguration.data becomes an instance
of PersistentData. PersistentData and ModuleConfiguration are often
referenced both as Configuration.
The key features of a configuration objects are:
they can be serialized and de-serialized from JSON data
they contains enough information to automatically generate
a UI panel to control it (as in flux-builder apps)
they can be adjusted at execution time using Adaptor
Behind what is called "module's configuration" there can be 3 different states depending on the context:
default configuration: the one constructed from empty data (default hard coded values are used, see this example)
static configuration: the one provided at the module's construction
dynamic configuration: the one provided to the onTrigger callback of
a module's input
To better understand the difference between them and see how it relates to adaptors,
let's examine a practical example.
The case study is to control the threshold parameter of the configuration of a
simulatorMdle using a sliderMdle (it is somehow in line with the example presented in core-concepts).
import {SliderModule, SimulatorModule, PhysicalModel, SolverModel} from'...'letbranch = ['|~sliderMdle~|-----=A|~simulatorMdle~|']letmodules = instantiateModules({sliderMdle:SliderModule,simulatorMdle: [SimulatorModule, {threshold:1e-8}]}) // we use hard coded PhysicalModel & SolverModel (focus on configuration here)letadaptors = {A : ({data,context}) => ({data: [newPhysicalModel(), newSolverModel()],context,configuration:{threshold:data} })}letgraph = parseGraph( { branch, modules, adaptors } )newRunner( graph ) letdiv = document.createElement("div")div.innerHTML = "`<div id='sliderMdle'> <div>`"renderTemplate(div,graph.workflow.modules)letsliderDiv = div.querySelector("#sliderMdle") asHTMLDivElement// Unit test tip: we can then simulate event with sliderDiv.dispatchEvent(...)// and make sure the simulatorMdle is reacting appropriately
In the above example we can distinguish the terms default configuration
and static configuration looking at the call to instantiateModules:
there is no information about configuration for the sliderMdle,
the configuration will get instantiated from an empty JSON: this is
the default configuration of the module
regarding the simulatorMdle, a threshold parameters is provided to
initialize the configuration, the resulting instance is referenced
as static configuration (it is ≠ from default configuration)
To explain what is referenced by dynamic configuration let's look at the data flow (the branch variable):
sliderMlde event send a number in its output
it is intercepted by the adaptorA that forward the
message's data (i.e. the slider value) to the property threshold of the adapted configuration
(that is to say: the configuration property of the adaptor's returned value).
the simulatorMdleonTriggered callback gets feeded by the static configuration
merged with the adapted configuration: the threshold property is not anymore 1e-8
but whatever the slider emitted. Merging the static configuration with the adapted
configuration is what is called dynamic configuration
🤓 It follows: the only place where the dynamic configuration is defined
is inside the triggered functions of a module (provided at ModuleFlux.addInput)
Configuration
The module configuration is a thin wrapper around the PersistentData provided by the developer into the module's namespace. It is automatically generated when using the Flux decorator. Once instantiated, the ModuleConfiguration.data becomes an instance of PersistentData. PersistentData and ModuleConfiguration are often referenced both as Configuration.
The key features of a configuration objects are:
Behind what is called "module's configuration" there can be 3 different states depending on the context:
To better understand the difference between them and see how it relates to adaptors, let's examine a practical example.
Case study
The case study is to control the threshold parameter of the configuration of a simulatorMdle using a sliderMdle (it is somehow in line with the example presented in core-concepts).
The 'application' is constructed using the utility functions (instantiateModules, parseGraph, Runner & renderTemplate) provided in the library for unit testing:
In the above example we can distinguish the terms default configuration and static configuration looking at the call to instantiateModules:
To explain what is referenced by dynamic configuration let's look at the data flow (the branch variable):