-
Notifications
You must be signed in to change notification settings - Fork 877
docs(dependency-injection): revise Dart and TS code and prose #1573
Conversation
@Foxandxss @wardbell @thso @kwalrath : this is ready for review. As usual, it is less painful to view the diff while ignoring changes in whitespace (such as indentation). |
@@ -11,6 +11,7 @@ import 'user_service.dart'; | |||
//PENDING: check whether we intend to hide injector_component.dart & providers_component.dart; if so, change docregion name? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this comment really be visible? Also, it doesn't reflect test_component.dart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was an old comment that I missed (I had only searched for todo|fixme). I have removed it since it is not relevant (the entire source file is never shown).
I have nothing to add, @kwalrath is doing an awesome job on the review. Sounds fine for me. |
|
||
Our `HeroService` *requires* a `Logger`, but what if it could get by without | ||
a logger? | ||
As is illustrated next, we can indicate that to the dependency injection |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds very formal. Also, we should mention @Optional()
in the text, not just in the code. Maybe:
We can tell Angular that the dependency is optional by annotating the constructor argument with @Optional()
:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds very formal ...
Yes, what you propose is much better, thanks. Fixed.
85bc650
to
d627229
Compare
:marked | ||
Then inject that class and its configuration information: | ||
+makeExample('dependency-injection/dart/lib/providers_component.dart','providers-7')(format=".") | ||
The problem with using `Map` as a token, is not that it is an abstract |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really long sentence, and it continues the thought of the previous paragraph. Let's shorten this sentence and combine the two paragraphs. Maybe:
But what should we use as the token? We can't use Map
because it's too general purpose. Our app might depend on several maps, each for a different purpose.
Dart difference: Interfaces are valid tokens
... are just class names. Map
is a valid token even though it's the name of an abstract class; it's just unsuitable as a token because it's too general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed per our discussion
Looks great! The only real problem I saw was the "key benefits of defining a configuration object class" paragraph, which needs to be clarified and probably broken up. |
d627229
to
40ba9a1
Compare
@Foxandxss & @wardbell: I don't know the TS side, so you still might want to take a look to make sure the new text is OK by you... |
Will look |
40ba9a1
to
dbcff2d
Compare
Updates done.
That paragraph has been reworked. |
The Dart [cascade notation][cascade] (`..`) provides a convenient means of initializing | ||
a configuration object. | ||
|
||
Use of the cascaded initialization idiom |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the right track, but this could still be simplified. Maybe:
If we use cascades, the configuration object can't be declared const
and we can't use
a value provider. The solution is to use a factory provider:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, what you propose is better. Done.
I had a couple more quibbles about the cascade wording, but otherwise LGTM. |
Updates done. |
Contributes to angular#1508 and angular#1522. - The main change on the TS side is to present best practices first, rather than presenting sample code and then saying "don't do that". - The "Optional dependencies" section has been moved towards the end of the provider variants section and its sample code has been simplified. - Reworked *_1.{ts,dart} sources so that main_1.{ts,dart} can actually be run, which helped find some bugs in those sources. - Despite angular/angular#8928, the Dart and TS OpaqueToken sections have been left in the prose. They can be revisited later. Enhancements to the Dart code include: - Added TestComponent. - Added a provider sample that makes use of an app config Map (to match TS); also added the more Dart-like use of a custom app configuration class, whose instance is initialized via the cascade operator. - Fixed Engine class hierarchy so that a single field named `cylinders` is defined (rather than two fields: one in the Engine supertype and one in the subclass), because having two fields is a bad design smell. - Similarly, fixed Logger hierarchy so that a single field named `logs` is defined. Also made `logs` a read-only field. - Reintroduced the SilentLogger().
933f683
to
118d4a5
Compare
LGTM. I'll merge this unless someone screams NO... |
Contributes to #1508 and #1522.
Enhancements to the Dart code include:
cylinders
is defined (rather than two fields: one in the Engine supertype and one in the subclass), because having two fields is a bad design smell.logs
is defined. Also madelogs
a read-only field.