AngularJS 模块与 CommonJS/ECMA6 模块

AngularJS modules vs CommonJS/ECMA6 modules

本文关键字:模块 ECMA6 AngularJS CommonJS      更新时间:2023-09-26

我加入了一个正在进行的Web项目,其中前端用Angular 1编写为MVC框架,并使用Webpack作为构建系统,我感觉就像MATRIX 2中的Neo在一堆嵌套矩阵中。

该项目被拆分为单独的.js文件,每个文件都以 CommonJS 样式(带 requiremodule.exports)或 ECMA6 风格(带 import s 和 export s)作为模块进行注释。Webpack 使用 Babel 将 ECMA6 转译为 ECMA5,并从中创建单个捆绑包。

在这些 CommonJS 模块中驻留着 AngularJS 模块。生活在CommonJS内部,Angular使用Angular的RequireJS式模块系统完成自己的依赖注入任务。

我觉得同样的依赖管理工作已经完成了两次。

在编写 Angular 时,Angular 开发人员是否认为多模块 Angular 项目应该简单地连接起来,例如grunt concat到一个捆绑包中并提供给客户端,其中 Angular $injector 负责依赖管理?那么,我们的 Webpack 构建只是在此之上的过度复杂化吗?


项目示例:

文件model.module.js

import angular from "angular";
import {EntityViewController} from './entity_view_controller'
// @ngInject
function routes($stateProvider) {
    $stateProvider.state("modeller.entity.view", {
        url: "/:id/view",
        controller: EntityViewController,
        templateUrl: "/states/modeller/model/entity_view.html"
    });
}
export default angular.module("states.modeller.entity", [])
    .config(routes)
    .controller("EntityViewController", EntityViewController);

文件entity_view_controller.js

"use strict"
export /* ngInject */ function EntityViewController($scope, $stateParams, EntityModel) {
    $scope.entity = {};
    $scope.attributes = [];
    EntityModel.get({id: $stateParams.id}, (data) => {
        $scope.entity = data.entity;
        $scope.attributes = data.attributes;
    });
}

的确,Angular 对 concat 友好,不需要其他模块化解决方案。一些开发风格(特别是JP)暗示使用IIFE来避免全局命名空间污染。可以手动编写IIFE或将此工作委托给Webpack或其他模块化系统。

模块化系统的使用引入了不适合普通JS的设计解决方案。

Angular

组件(例如控制器)中的类继承在 Angular DI 中是丑陋的。当在应用程序范围内使用带有IIFE模块的类时,可能需要手动维护导出 - 同样,这是模块化系统的工作。

相当数量的应用程序组件可能与框架无关,这扩展了架构决策的选项(框架迁移、同构应用程序),并允许将这些单元与框架分开测试。

JS模块和Angular模块/DI在我的经验中可以很好地协同工作。