Question

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

项目被拆分为单独的.js文件，每个文件都以CommonJS样式（require和module.exports）或ECMA6样式（带import s）注释为模块。 export S）。 Webpack使用Babel将ECMA6转换为ECMA5并从中创建一个捆绑包。

在这些CommonJS模块中驻留AngularJS模块。生活在CommonJS中，Angular使用Angular的RequireJS-esque模块系统完成自己的依赖注入任务。

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

是不是真的，在编写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;
    });
}

Answer 1

Angular确实是concat友好的，不需要其他模块化解决方案。一些开发风格（特别是JP）意味着使用IIFE来避免全局命名空间污染。可以手动编写IIFE或将此作业委托给Webpack或其他模块化系统。

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

Angular组件（例如控制器）中的类继承对于Angular DI来说是丑陋的。当在应用程序范围内使用IIFE模块的类时，可能需要手动维护导出 - 再次，这是模块化系统的工作。

大量的应用程序组件可以与框架无关，这扩展了架构决策（框架迁移，同构应用程序）的选项，并允许单元与框架分开测试。

根据我的经验，JS模块和Angular模块/ DI很好地结合在一起。

AngularJS模块与CommonJS / ECMA6模块

1 个答案: