[Research][Embeddable Variables] Initial Project Description #134706
Labels
enhancement
New value added to drive a business result
Feature:Dashboard
Dashboard related features
Feature:Embeddables
Relating to the Embeddable system
Feature:Input Control
Input controls visualization
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
loe:x-large
Extra Large Level of Effort
Project:Controls
Team:Presentation
Presentation Team for Dashboard, Input Controls, and Canvas
Projects
Describe the project
There are a few use cases - for example #134592 and #134591 which require Embeddable Containers to pass input to their children which overrides the child's input. We will need to provide a mechanism for this type of inheritance. This mechanism should act as a standardized system for any future / existing requirements that involve a container storing state which should override one or more configuration options on its children.
In general, a generic container should not store state for any specific type of embeddable without a system in place to handle it generically. This issue is an initial exploration of how something like that could be built.
Rough Diagram
Concepts
Variable Controls
A new and totally separate type of Control should be built that interacts with variables instead of data. Creating / editing these controls would be a separate experience from the data controls, but they should exist in the same bar and look similar.
Each variable type will come with its own variable control embeddable, factory, and its own inline editor the same as controls do. UX-wise, when creating a variable control the user will be prompted with a list of types that they need to choose from.
Variable controls store all of their configuration with the Control Group Input, including initial / default selections. These controls publish their selections as
output
to the Control Group which in turn publishes all of itsVariables
into itsoutput
along with itsfilters
.A container like the Dashboard Container could subscribe to these output changes, and update its Variable Store accordingly.
Variable Store
Any embeddable container could implement a new interface
IVariableStore
which would be used to store variables.The
IVariableStore
interface would look something likeNote The variable store is meant to be ephemeral. It should not be stored in a saved object. The variable store is only an intermediary, and a communication method for inheritance. Any variable values which are saved should be saved in the Control Group to allow for extract / inject / migrations.
Variable Slots
Any embeddable could implement a new interface
IVariableSlotEmbeddable
which would provide methods for getting all variable slots. These can be hardcoded, or determined by the embeddables current state. Each Variable slot would follow an interface similar to:Variable Inheritance
If a container extends
IVariableStoreEmbeddable
it can pass the appropriate variables down to the child during thegetInputForChild
method. First the container would check if the current embeddable extendsIVariableSlotEmbeddable
, and if it does the container would:Variable Assign Action
If the embeddable extends
IVariableSlotEmbeddable
, and its parent extendsIVariableStoreEmbeddable
a new action should be compatible which opens a flyout that allows users to select variables by their ID / display name for each slot that the embeddable features.The text was updated successfully, but these errors were encountered: