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

docs(dependency-injection): revise Dart and TS code and prose #1573

Merged
merged 3 commits into from
Jun 3, 2016

Conversation

chalin
Copy link
Contributor

@chalin chalin commented Jun 1, 2016

Contributes to #1508 and #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 OpaqueToken cannot be implemented in Dart 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().

@chalin
Copy link
Contributor Author

chalin commented Jun 1, 2016

@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?
Copy link
Contributor

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.

Copy link
Contributor Author

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).

@Foxandxss
Copy link
Member

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
Copy link
Contributor

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():

Copy link
Contributor Author

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.

@chalin chalin force-pushed the chalin-dep-inj-0525 branch from 85bc650 to d627229 Compare June 1, 2016 23:44
: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
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed per our discussion

@kwalrath
Copy link
Contributor

kwalrath commented Jun 2, 2016

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.

@chalin chalin force-pushed the chalin-dep-inj-0525 branch from d627229 to 40ba9a1 Compare June 2, 2016 17:24
@kwalrath
Copy link
Contributor

kwalrath commented Jun 2, 2016

@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...

@wardbell
Copy link
Contributor

wardbell commented Jun 2, 2016

Will look

@chalin chalin force-pushed the chalin-dep-inj-0525 branch from 40ba9a1 to dbcff2d Compare June 3, 2016 00:47
@chalin
Copy link
Contributor Author

chalin commented Jun 3, 2016

Updates done.

Looks great! The only real problem I saw was the "key benefits..." paragraph

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
Copy link
Contributor

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:

Copy link
Contributor Author

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.

@kwalrath
Copy link
Contributor

kwalrath commented Jun 3, 2016

I had a couple more quibbles about the cascade wording, but otherwise LGTM.

@chalin
Copy link
Contributor Author

chalin commented Jun 3, 2016

Updates done.

chalin added 3 commits June 3, 2016 05:22
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().
@chalin chalin force-pushed the chalin-dep-inj-0525 branch from 933f683 to 118d4a5 Compare June 3, 2016 12:22
@kwalrath
Copy link
Contributor

kwalrath commented Jun 3, 2016

LGTM. I'll merge this unless someone screams NO...

@kwalrath kwalrath changed the title docs(dependency-injection): revised Dart and TS code and prose docs(dependency-injection): revise Dart and TS code and prose Jun 3, 2016
@kwalrath kwalrath merged commit 05864c2 into angular:master Jun 3, 2016
@chalin chalin deleted the chalin-dep-inj-0525 branch June 3, 2016 18:36
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants