[API] API Redesign Goals and Proposals #69
Conversation
Conflicts: docs/src/design/proposals/APIRedesign.md
WTD-1237
VWoeltjen
changed the title
Add note about RequireJS as a dependency injector facilitating use from web workers, as noted in comments to #141
|
|
||
| ## Get rid of "extension category" concept. | ||
|
|
||
| The concept of an "extension category" is itself an extraneous concept-- an extra layer of interface depth, an extra thing to learn before you can say "hello world". Extension points should be clearly supported and documented with whatever interfaces make sense. Developers who wish to add something that is conceptually equivalent to an extension category can do so directly, in the manner that suites their needs, without us forcing a common method on them. |
There was a problem hiding this comment.
I think I agree with this.
What I want to avoid is providing multiple interfaces for the same thing. For instance (assuming the "register during config" approach):
mct.config(['fooProvider', 'barProvider', function (fooProvider, barProvider) {
fooProvider.registerFoo(myFoo);
barProvider.bars.push(myBar);
}]);...would be bad (increase number of interfaces needlessly.) We should have/use a common RegistryProvider.<T> interface for these (and, ideally, some implementation(s) that can be reused if plugins wish to introduce extension points):
mct.config(['fooProvider', 'barProvider', function (fooProvider, barProvider) {
fooProvider.register(myFoo);
barProvider.register(myBar);
}]);This fills the same role as extension categories, so I'm not sure if that would contradict this proposal or not. I agree that we shouldn't force a common method, but we shouldn't prevent using a common method either.
There was a problem hiding this comment.
This proposal is a "policy statement" about how we communicate these concepts to developers and users more so than a specific requirement for code.
Yes, Registering providers should have consistent syntax, but that's just good programming; it's not a feature.
The developer guide should show how to extend the platform while introducing the bare minimum number of concepts. "RegistryProvider" is a concept that they just don't need to know about.
Particularly, closing API-related issues; need for this mentioned at #264 (comment)
Bring over tables indicating consensus/decisions about proposed API changes from #263
|
Added decisions from #263 to proposals, as well as plans from #264. Would like to merge into master at this point to formalize decisions/plans. All outstanding work (both pending decisions and plans) is linked to open issues. Author Checklist
|
Reviewer Checklist
|
[API] API Redesign Goals and Proposals
Creating a pull request to allow comments in-line.