Sharing data & state between components

[KingOfTac]

Looking to spark a discussion into methods to enable components to communicate with each other without becoming dependencies of each other.

Background

A situation I run into sometimes is I need to create a generic-like wrapper component that can add extra functionality to, or manage state between other components. A simple example would be Telerik's Cascading ComboBox, and a more complex case is WinUI's SemanticZoom. Both examples have different use cases and requirements, but the common theme here is they both have a wrapper element around some general use controls that is able to share data and state with all of its children.

Goals

• I think in its current state, FAST is definitely capable of this, so I'm looking for ideas or suggestions that remain in the scope of FAST's current capabilities.
• A wrapper element should be able to host any set of elements that fit its data model without those elements becoming dependencies of the wrapper or the wrapper reimplementing the elements within itself.
  • For example, a web component version of SemanticZoom should be able to wrap any elements capable of displaying grouped data, without ever knowing what those elements are internally as long as they provide the information it needs to hook into them and manage the view changes between the group level data and the item level data.
  • In the case of the CascadingComboBox the wrapper should support the native select element as well as web components that implement select or combobox.

Current Ideas

• Component Interop could work using observables, however I'm not sure if the wrapper will need to know the implementation details of other components which is what I'm trying to avoid.
• Using DI. I haven't used DI for anything other than registering api endpoints with components, so I'm not sure what the challenges or drawbacks are.
• Event listeners. The wrapper listening to events on elements definitely does require that it knows the implementation details of those elements, however there is a way that it doesn't have to although it would be a bit tedious.
  • For every element that you want supported by the wrapper you would have to create an additional wrapper specifically for that element that would listen for events and then emit a new event that the wrapper could listen for. This way the wrapper only needs to care about listening for the handful of events it needs to instead of trying to handle every case for every supported element. This method can also be bi-directional for when the wrapper needs to update one of its children's state.
  • This biggest drawback to this approach is you would need to create 1+n wrapper elements where n is elements you want supported.

[EisenbergEffect]

Clarifying question: Does the wrapper need to get data from the children or do the children need data from the wrapper or does it need to go both ways?

[KingOfTac]

I think it would need to go both ways somehow, but ultimately it would depend on the specific component being created.

[EisenbergEffect]

Ok, you've got a few options.

If you want the parent component to work with any direct child, then I recommend that you use the slotted directive to keep a sync'd array of child nodes and get change notifications when children change. When a change happens, you can loop through the slotted children and manipulate them in whatever way you want. So, if you want to check them to see if they support a specific API, such as having a value property, you could do that. The nice thing about this is that the logic is in a single element (the parent) regardless of what type of child you add. As long as the child elements conform to some interface, the parent can work with them. If you need child nodes that are not direct children, then you could use the children directive. Be aware that this creates a MutationObserver and could get expensive. In this case, you might want to consider an event strategy, described next.

If you have more complex structures involved, you may want to have children fire events. Using the details property of the custom event, you can pass any data you want. You can even pass a custom object with its own API. The parent element then only needs to know about the event name and the details data type. This will work better with more complex DOM structures. However, be aware that perf may degrade if you have many children raising events all the time.

A third option is to use a shared state or service object, provided by DI. The shared object can be injected into the parent and injected into the children. This object can then be used as a communication channel between the two. By default, the DI system makes these singletons. So, if you have multiple instances of the parent element in your app, and you don't want all parents sharing the same object, you need to explicitly handle that. One way you can do that is by creating a new DI container, scoped to the parent element. Then explicitly register the shared service in that container and only descendants of that parent element will be able to inject that specific instance. Note that this works regardless of the DOM structure. The reason for this is that container location for an element works using the event pattern described above. It's just a very general purpose solution built on top of that, which adds object lifetimes and other features. The mechanism also has some perf optimizations that enable it to avoid events for container location in certain scenarios if needed.

A fourth option is that you could create an event aggregator that enables non-DOM based pub/sub, and use that to communicate between elements. Because this isn't DOM-based, it's not best suited if you need parent/child communication. However, you can put the event aggregator in DI and use the same technique as above. I personally only use event aggregator when I need one global aggregator to facilitate communication between components independent of DOM structure. This tends to focus around loosely coupled business events. So, imagine you have a Auth service and it raises an event when the user is logged in/out. You could have components across your entire app subscribe to that domain event and respond in their own way.

Hope this helps!

[KingOfTac]

I have just about every option worked out now except for the DI. I think I have setting up the parent container down, but I just can't seem to wrap my head around injecting the shared state into the child components. Here's what I have stubbed out so far.

class ComponentState {
    public get state() { }
    public set state(val) { }
}

// Not sure if this is correct, but trying to follow the docs as best I can.
class MyWrapper extends FoundationElement {
    public container!: Container;
    public componentState!: ComponentState;

    @observable slottedChildren: HTMLElement[];
    public slottedChildrenChanged() {
        if (
            this.$fastController.isConnected &&
            this.container &&
            this.componentState
        ) {

        }
    }

    public connectedCallback() {
        super.connectedCallback();

        this.container = DI.getOrCreateDOMContainer(this);

        this.container.register(
            Registration.instance(this.componentState, ComponentState)
        );
    }
}

[EisenbergEffect]

Try something like this if you want all child components to share a state object coming from the parent:

class ComponentState {
    public get state() { }
    public set state(val) { }
}

class ParentComponent extends FASTElement {
    constructor() {
      super();

      // Create a new DI container that is scoped to this element.
      const scopedContainer = DI.getOrCreateDOMContainer(this);
      scopedContainer.register(
        // explicitly register the state at this scope level
        Registration.singleton(ComponentState, ComponentState)
        // Or if you already have an instance
        // Registration.instance(ComponentState, stateInstance);
      );
    }
}

class ChildComponent extends FASTElement {
  @inject(ComponentState) state!: ComponentState; // state injected
}

[KingOfTac]

I see now. I think what was confusing me was my question about using the existing fast/fluent components. For context, I was thinking of something like this when writing the final markup:

<fast-parent-component>
   <fast-tree-view></fast-tree-view>
</fast-parent-component>

I think the above will most definitely work with option-1, but for the DI approach if I wanted something like TreeView supported I would have to do something like:

class ChildComponent extends TreeView {
  @inject(ComponentState) state!: ComponentState; // state injected
}

<fast-parent-component>
   <fast-child-component></fast-child-component>
</fast-parent-component>

I apologize if I'm still not getting it. DI is still a bit of a foreign topic for me, so I'm trying to learn everything I can at a rapid pace.

[EisenbergEffect]

Yes, that's correct. With the code above, it's probably best to go with the slotted approach. If you wanted to use DI, you would need to inherit and add code for the injection as well as any new behavior that used that.

Since I personally try to avoid inheritance, I'd lean towards creating my own parent component in this case. It would have all the logic and just detect.interact with children through slotted.

[KingOfTac]

Circling back on this. I wanted to share what has worked for me that was a result of this discussion. In order to meet my goal of having a container element that is capable of containing any combination of elements or components to add to or enhance their current capabilities, I ended up using a combination of the event and slotted approaches.

One such container element that I have prototyped takes two elements as children, each in a different named slot. The host element has click and keyboard events attached to it so that it can essentially listen for those events through its entire subtree. To avoid needing to create specific components as children or extend existing components, data is passed to the parent through data attributes. The event handlers on the container watch for specific attributes, and if they don't exist the handlers just return.

This approach has allowed me to create "good enough" generic component containers that enable wiring up more complex UI patterns and interactions through markup, without a ton of extra javascript and special-purpose components.