-
Notifications
You must be signed in to change notification settings - Fork 38
External data property and children injection #648
Description
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 DNode
s 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