Another way type () in angular dart

I made a dart angular tutorial and I have a question about this.

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.

You can have hundreds of types in a large application, so this is a weird way to declare all types.

Is there any other way to do this?

Thanks.

+6
source share
2 answers

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

EDIT
Reflection may work, but when you start using special cases, it becomes unreadable very quickly.
When you use DI, situations often arise when a class constructor requires an object of type InterfaceX , and you want to specify which of the classes that satisfy the requirement (implement an interface) should actually be entered. Then you start coding special cases with reflection.
Using type(InterfaceX, implementedBy: Y); always super readable.
EDIT END

I don’t know if you see it as an improvement, but what we did (and I saw in several projects)

Create more modules and add them to MyAppModule with install

see, for example, on the site - 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()); } } 
+3
source

Here are my thoughts as someone relatively new to angular dart. This does not directly answer your question, but I hope it will be useful.

Firstly, it is generally considered that it is “bad” to use globals in programming. However, if you start working with the framework, you do not have time to learn all the best practices, and since your application starts with a tiny one, it’s good to use several globals. In the end, you're refactoring when you learn best practices, but you need to have a few shortcuts when creating a small application. With Web Sites Routes are effectively global, but even on a large site you only have a few hundred before you split your site into several sites. Similarly used for IMO types.

really effective as global variables in a program. This is because there is only one html DOM, and therefore the selectors inside this dom need to know about the other selectors in order to avoid a collision. (selectors are similar to globals in a sense - the same with css - although we could reuse selectors for different types in different views to confuse css relationships, as well as add another complication when trying to read the html source and return to the dart code (you will need to decide which view is active, etc.), and then when you decide to combine the selectors in the same view, everything becomes even more difficult when you need to rename one of them)). Basically, to avoid selectors that interfere with selectors, we need to avoid types that interfere with IMO types. Having types effectively as global is probably the cleanest way to solve this problem with the current state of html.

Also because single-page applications should not be too large, I recommend a “flat code” over a “nested code”, although it is good to have a balance. Although the components of single-page applications can be complex with lots of code, I don’t think you need so many types. 100 types must be manageable. Once you get more, it is probably a good idea to create a new application. Otherwise, your one-page application is likely to be too complicated for users and will load slowly, etc.

+1
source

All Articles