3 ms·

Completely agree. I don't see many people in the React community advocating the use of DI though, so that's a plus. The DI in Angular made a little bit of sens

by dceddia 10y ago

Completely agree. I don't see many people in the React community advocating the use of DI though, so that's a plus. The DI in Angular made a little bit of sense because JS modules weren't very widespread back then. But now, with ES6 imports (and/or 'require') there's no need. We have real modules now, and they can be dynamically injected for testing purposes with something like inject-loader[0]. I think Angular and/or DI's popularity has something to do with Java devs learning frontend development, and feeling more comfortable with more structure. [0] https://github.com/plasticine/inject-loader https://github.com/plasticine/inject-loader

_greim_ 10y ago
Makes sense. My frustration in part stems from having worked on an app that used Angular DI and a module loading system (RequireJS) side by side. The conceptual dissonance and fallout between the two systems was an endless source of bickering and confusion for the team. I came to the situation having worked on a CommonJS/Browserify project, and it was like walking into a brick wall.
- dceddia 10y ago
  I worked on a project that had Angular + RequireJS too. I don't think having RequireJS added anything at all. It was just additional overhead - every module we added caused at least 3 files to change. We eventually ripped it out and just dealt with Angular's own module system.
Bahamut 10y ago
This is a misunderstanding of what Angular's DI is meant to solve - it is orthogonal to Angular 1's module system. DI is meant to solve runtime dependency management, which is a different problem from modularity, which is what ES6 modules are meant to solve. For example, oftentimes one has a class that may have an instance floating around. One does not want to instantiate it unnecessarily if it already exists oftentimes, and so the injector will handle that automatically if necessary by instantiating an instance if it doesn't exist already, allowing for efficient memory management of services. It also has a major benefit for facilitating easier patterns for testing & readability. Angular 1's DI has a poor API signature, with the naive allowance of it through a hacky regex, and crappy duplication of string references for the regular usage with minification taken into account - Angular 2's is built much more solidly and without such hacks. It should also be noted that using cjs for dynamic injection is a bit of a hack as well, since it is a non-standard syntax. Angular 2's DI is much more pure, as it could be split off into a standalone library with some build configuration with zero external dependencies other than perhaps an ES6 shim like core.js.

by dceddia 10y ago

_greim_ 10y ago

Makes sense. My frustration in part stems from having worked on an app that used Angular DI and a module loading system (RequireJS) side by side. The conceptual dissonance and fallout between the two systems was an endless source of bickering and confusion for the team. I came to the situation having worked on a CommonJS/Browserify project, and it was like walking into a brick wall.

dceddia 10y ago
I worked on a project that had Angular + RequireJS too. I don't think having RequireJS added anything at all. It was just additional overhead - every module we added caused at least 3 files to change. We eventually ripped it out and just dealt with Angular's own module system.

Bahamut 10y ago

This is a misunderstanding of what Angular's DI is meant to solve - it is orthogonal to Angular 1's module system. DI is meant to solve runtime dependency management, which is a different problem from modularity, which is what ES6 modules are meant to solve. For example, oftentimes one has a class that may have an instance floating around. One does not want to instantiate it unnecessarily if it already exists oftentimes, and so the injector will handle that automatically if necessary by instantiating an instance if it doesn't exist already, allowing for efficient memory management of services. It also has a major benefit for facilitating easier patterns for testing & readability. Angular 1's DI has a poor API signature, with the naive allowance of it through a hacky regex, and crappy duplication of string references for the regular usage with minification taken into account - Angular 2's is built much more solidly and without such hacks. It should also be noted that using cjs for dynamic injection is a bit of a hack as well, since it is a non-standard syntax. Angular 2's DI is much more pure, as it could be split off into a standalone library with some build configuration with zero external dependencies other than perhaps an ES6 shim like core.js.