angularjs

前言 每个框架都不可避免会有自己的一些特点，从而会对使用者有一定的要求，这些要求就是主张，主张有强有弱，它的强势程度会影响在业务开发中的使用方式。 一、Angular，它两个版本都是强主张的，如果你用它，必须接受以下东西： 必须使用它的模块机制 必须使用它的依赖注入 必须使用它的特殊形式定义组件（这一点每个视图框架都有，难以避免） 所以Angular是带有比较强的排它性的，如果你的应用不是从头开始，而是要不断考虑是否跟其他东西集成，这些主张会带来一些困扰。 二、React 它也有一定程度的主张，它的主张主要是函数式编程的理念，比如说，你需要知道什么是副作用，什么是纯函数，如何隔离副作用。它的侵入性看似没有Angular那么强，主要因为它是软性侵入。你当然可以只用React的视图层，但几乎没有人这么用，为什么呢，因为你用了它，就会觉得其他东西都很别扭，于是你要引入Flux，Redux，Mobx之中的一个，于是你除了Redux，还要看saga，于是你要纠结业务开发过程中每个东西有没有副作用，纯不纯，甚至你连这个都可能不能忍： const getData = () => { // 如果不存在，就在缓存中创建一个并返回 // 如果存在，就从缓存中拿 } 因为你要纠结它有外部依赖，同样是不加参数调用，连续两次的结果是不一样的，于是不纯。为什么我一直不认同在中后台项目中使用React

DevUI是一支兼具设计视角和工程视角的团队，服务于华为云 DevCloud 平台和华为内部数个中后台系统，服务于设计师和前端工程师。 官方网站： devui.design Ng组件库： ng-devui （欢迎Star） 引言 重构，是我们开发过程中不可避免需要进行的一项工作。重构代码，以适配当前模块设计之初未考虑到的多样化场景，并增加模块的可维护性、健壮性、可测试性。那么，如何明确重构的方向，以及量化重构的结果呢？ 代码圈复杂度（Cyclomatic complexity，CC）可以是一个供选择的指标。 什么是圈复杂度 圈复杂度（Cyclomatic complexity，CC）也称为条件复杂度或循环复杂度，是一种软件度量，是由老托马斯·J·麦凯布（Thomas J. McCabe, Sr.）在1976年提出，用来表示程序的复杂度，其符号为VG或是M。圈复杂度即程序的源代码中线性独立路径的个数。 为何要降低模块(函数)的圈复杂度 下表为模块（函数）圈复杂度与代码状况的一个基本对照表。除了表中给出的代码状况、可测性、维护成本等指标外，圈复杂度高的模块（函数），也对应着高软件复杂度、低内聚、高风险、低可读性。我们要降低模块（函数）的圈复杂度，就是要降低其软件复杂度、增加内聚性、减少可能出现的软件缺陷个数、增强可测试性、可读性。 圈复杂度 代码状况 可测性 维护成本 1 - 10

问题： In the "Create Components" section of AngularJS's homepage , there is this example: 在 AngularJS主页 的 “创建组件”部分中 ，有以下示例： controller: function($scope, $element) { var panes = $scope.panes = []; $scope.select = function(pane) { angular.forEach(panes, function(pane) { pane.selected = false; }); pane.selected = true; } this.addPane = function(pane) { if (panes.length == 0) $scope.select(pane); panes.push(pane); } } Notice how the select method is added to $scope , but the addPane method is added to this . 请注意如何将 select 方法添加到 $scope ，但是将 addPane 方法添加到 this 。 If I change it to $scope.addPane , the

因为博客园改版，导致这个系列的第一篇博客无法正常显示，所以另外copy了一篇 导航： C#开发微信小程序系列 微信小程序相比于微信公众号的开发，区别在于微信小程序只请求第三方的数据，整个界面的交互（view）还是在微信小程序上实现，前后端完全分离，说白了，微信小程序开发与具体的后台语言无关，C#，Java，Python都行，只要前端UI开发完成，访问对应的数据服务接口，就成了，上手还是蛮简单的，而微信公众号的开发，是直接请求第三方的web界面。所以说微信小程序更轻量级，用来做一些餐饮店在线点单，小小的网上商城什么的，还是很方便的，不过有一个比较坑的地方是 微信小程序 要求必须通过 HTTPS 完成与服务端通信， 对于我这种只是来学习的人来说，还要购买SSL证书，然后搭建一个站点，也太麻烦了一点，那怎么办呢？其实，只要新建小程序的时候，不使用AppID来登录，就不会对https做校验了，当然，如果你要最终发布，还是需要搭建https的站点的，腾讯云or阿里云都可以申请免费的SSL证书。 批注：如果要正式发布，首先需要租用一台服务器至少3个月，并拥有一个固定IP，其次就是要购买域名以及SSL证书，当然域名有便宜的1块钱，SSL证书也有免费的可以使用，最后就是在网站发布后，要申请域名备案。一切准备妥当，小程序就可以上线了。 微信小程序官方文档： https://developers

话说这天，我们团队开会讨论了一个问题，不，与其说“讨论”，不如说“争吵”更合适。 背景是这样的： 我们要开发一个 xxx 后台管理系统，这个系统业务复杂、功能又多，大家的争吵集中在“这个系统是否应该用前后端分离的方案”。 这次争吵的问题比较典型，于是我就写了这篇文章。为了大家好理解，把“xxx 后台管理系统”泛化一下，变成： 开发一个大型后台管理系统，应该用前后端分离的技术方案吗？ 先说一下，本文中的观点肯定有人不认同，再加上我对前端技术掌握有限，所以大家批判的看吧。 1. 先审题，冷静的分析一下 前后端分离的优点多多，这不需要多说，大家人人都清楚。 来，讨论之前，我们先一起好好审审题。 结合“ 开发一个大型后台管理系统 ”这个约束条件，冷静的分析一下： • 什么是后台管理系统：首先后台管理系统这个称呼，意味着这是一个 B 端系统 。可以小到部门级应用（客户投诉登记系统、办公设备台账系统），大一点可以是大集团级核心系统（500 强保险公司客服、呼叫中心），可以是 ERP、CRM、OA（SAP、用友、泛微协同），可以是一个 B2C 电商的商城后台、支付网关管理控制台，可以是 Saas 的管理后台（Salesforce、Teambition、Jira），可以大到阿里云控制台…… • 什么是大型：我理解大型系统是指功能模块多、交互复杂，而不是访问量、TPS、数据量大。所以 CMS、OA