Skip to content
This repository was archived by the owner on Jul 30, 2018. It is now read-only.
This repository was archived by the owner on Jul 30, 2018. It is now read-only.

External data property and children injection  #648

@agubler

Description

@agubler

Enhancement

State injection is currently supported using the Container, a HOC pattern to inject a non presentational widget into the tree that works well for simply injecting state/functions etc but does not work nicely when a mixin needs to inject state. Currently ThemeableMixin supports "self" injection of state by leveraging the @beforeRender and fully replacing the render function with a w call for the Injector in the registry passing the render function as a property.

The main issue with this is that now the result from the widget that used ThemeableMixin is actually returned from the Injector render function so all the DNodes run through the injectors afterRenders and not the original widgets. Same for the registries, the registries used will be the registries available to the Injector and not the ones provided to the original widget.

This lead to some "hacky" changes within the Injector to try and ensure that the correct scope was bound to functions as they were called or for when they would be called in the future.

It would be nice if we could support both styles of external state injection without the need for these "workarounds" and should ensure that the additional workarounds are not required as features are added in the future.

We could potentially could add core support for injection from a context that is stored in the registry (that does not extend WidgetBase) within WidgetBase using the decorator pattern. WidgetBase will run through the property injection and diff'ing internally each render.

@injector({
    name: 'registry-label',
    getProperties: (context: any, properties: any) => { return properties; }
})
class MyClass extends WidgetBase { }

or via the constructor using addDecorator.

This should give the building blocks to create the very similar mechanisms available today with Container/Injector (the container would become a true mixin again) but also support use cases where mixins need to inject properties from the registry. With all the required typing goodness too :)

We would not advocate using the injector standalone as above, instead provide out of the box mixins as well as give all the details needed to create their own mixin, that provides all the typings/usability/ergonomics that that users expect

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions