Skip to content
This repository was archived by the owner on Dec 4, 2017. It is now read-only.

Alternatives to OpaqueToken for use in dependency-injection (DI) chapter #1563

Closed
chalin opened this issue May 31, 2016 · 2 comments
Closed
Labels

Comments

@chalin
Copy link
Contributor

chalin commented May 31, 2016

OpaqueToken cannot be implemented in Dart, see angulardart/angular#35. I am opening this issue to hold a thread of discussion about alternatives for both the Dart and TS sides --- given that we want minimize difference across languages so as to provide a consistent UX. I'll focus the discussion on Dart, but the proposal holds for both.

For the purpose of this discussion, let's reuse the example given in the TS OpaqueToken section of the angular.io di chapter. Consider the following snippets of a Dart version of that example:

const APP_CONFIG = const OpaqueToken('app.config'); // Token definition
// ... providers
providers: const [const Provider(APP_CONFIG, useValue: CONFIG)]
// ... constructor
AppComponent(@Inject(APP_CONFIG) Config config) {...}

Given that an OpaqueToken is no better than a String in Dart, why not simply use an fresh type name introduced via an abstract class declaration:

abstract class APP_CONFIG {} // Token definition

Given that TS also has abstract classes, this approach could be used consistently across languages.

Thoughts @vicb @mhevery @wardbell @thso @kwalrath ?

@chalin
Copy link
Contributor Author

chalin commented Jun 1, 2016

Btw, another alternative to using an abstract class type name is to use a named function (closure) as a token.

void APP_CONFIG_TOKEN() {}

@chalin
Copy link
Contributor Author

chalin commented Dec 16, 2016

This issue was moved to dart-lang/site-webdev#256

@chalin chalin closed this as completed Dec 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants