Other way that type() in angular dart

问题:

I did the angular dart tutorial and I have a question about it.

To declare a type available for dependecy injection, I have to do this:

class MyAppModule extends Module {
  MyAppModule() {
    type(RecipeBookController);
  }
}

And so on for all types.

In a big app, you can have hundreds type, so it's a weird way to declare all types.

Is there any other way to do this?

Thanks.

回答1:

You can use reflection to collect the types. Please add a comment if you need more information about this approach (I try to avoid reflection in web apps).

EDIT
Reflection may work, but when you start using special cases it gets unreadable very fast.
When you use DI you often have situations where your class' constructor requires an object of type InterfaceX and you want to specify which of the classes that fulfill the requirement (implement the interface) should actually be injected. Then you start to code special cases with reflection.
Using type(InterfaceX, implementedBy: Y); is always super readable.
EDIT END

I don't know if you see this as an improvement but what we did (and I have seen in several projects)

Create more modules and add them to MyAppModule with install

see for example at
- https://github.com/akserg/angular.dart.ui/blob/master/lib/accordion/accordion.dart
- https://github.com/akserg/angular.dart.ui/blob/master/lib/angular_ui.dart

accordion.dart

class AccordionModule extends Module {
  AccordionModule() {
    type(AccordionComponent);
    type(AccordionHeadingComponent);
    type(AccordionGroupComponent);
    value(AccordionConfig, new AccordionConfig());
  }
}

angular_ui.dart

class AngularUIModule extends Module {
  AngularUIModule() {
    install(new AlertModule());
    install(new AccordionModule()); // the above module
    install(new ButtonModule());
    install(new CarouselModule());
    install(new CollapseModule());
    install(new DropdownToggleModule());
    install(new ProgressbarModule());
    install(new RatingModule());
    install(new TabsModule());
    install(new TimeoutModule());
    install(new TransitionModule());
    install(new ModalModule());
  }
}

回答2:

Here are my thoughts as someone relatively new to angular dart. This doesn't directly answer your question but I hope it's useful.

Firstly It's generally thought to be "bad" to use globals in programming. However if you're starting out with a framework, you don't have time to learn all of the best practices and since your app starts off tiny it's okay to use a few globals. Eventually you refactor as you learn better practices but you should be allowed to take a few shortcuts when building a small app. With websites, Routes are effectively globals but even on a large site you only have a few hundred before you split the site into multiple sites.. Similar applies for types IMO.

types are effectively like having global variables in a program. This is because there is only one html DOM and so selectors within that dom need to be aware of other selectors to avoid collision. (selectors are like globals in a sense - same with css - although we could reuse selectors for different types in different views, that would muddle the css relationship and also add one extra complication when trying to read the html source and refer back to the dart code (you would have to decide which view is active etc, and then when you decide to pull the selectors together into the same view things get further complex when you have to rename one of them)). Basically to avoid selectors colliding with selectors we need to avoid types colliding with types IMO. Having types effectively as globals is possibly the cleanest way to solve this problem with the current state of html.

Also because single page apps shouldn't be too large, I encourage "flat code" over "nested code" although it's good to have balance. While components of single page apps may be complex with lots of code I don't think you should need so many types. 100's of types should be manageable. Once you get more than that it's probably a good idea to build a new application. Otherwise your single page app is likely to be too complicated for the users and load slowly etc.