vidartf
commented
4 years ago I've been using this pattern for lab extensions:
// File defining tokens
import {TokenA} from 'amodule';
import {Token} from '@phosphor/...';
export interface TokenB extends TokenA {
myProp: string;
}
export const TokenB = new Token(...);// File defining plugins
import {TokenA, activateA} from 'amodule';
import {TokenB} from 'bmodule/lib/tokens';
const MyPluginB = {
provides: TokenB;
activate: (...) => {
const A = activateA(...);
A.myProp = 'foo!';
return A;
}
}
const MyPluginA = {
provides: TokenA;
requires: [TokenB];
activate: (..., B: TokenB) => {
return B;
}
}
export {MyPluginA, MyPluginB};
ellisonbg
sccolbert
@ellisonbg, @afshin, @blink1073, and I ran into a situation today where we wanted to introduce a token that would extend another token. In other words, (the object registered with) token B implements the interface of (the object registered with) token A, plus some extra stuff. Normal plugins would require token A, but some might require token B. It would be nice if the dependency injection framework could register that token B could be served to those requesting token A.
It just occurred to me that you could probably do this by writing a single activation function that is essentially memoized (first call runs and creates the system object, second or later calls just return some stored object), and register that activation function with both token A and token B. Or you could just have token B registered in a plugin, and write a new plugin for token A that requires token B and just returns it.
So this issue is about whether we should have an explicit pattern for registering tokens/interfaces that extend other tokens/interfaces. Or perhaps this issue is just documenting a pattern for doing so in the existing framework.