angularjs

问题： When should I store the Subscription instances and invoke unsubscribe() during the NgOnDestroy life cycle and when can I simply ignore them? 在NgOnDestroy生命周期中，什么时候应该存储 Subscription 实例并调用 unsubscribe() ？什么时候可以忽略它们？ Saving all subscriptions introduces a lot of mess into component code. 保存所有订阅会在组件代码中带来很多麻烦。 HTTP Client Guide ignore subscriptions like this: HTTP客户端指南 会忽略这样的订阅： getHeroes() { this.heroService.getHeroes() .subscribe( heroes => this.heroes = heroes, error => this.errorMessage = <any>error); } In the same time Route & Navigation Guide says that: 同时，《 路线与导航指南 》指出： Eventually, we'll

一、常见的搜索功能 <input nz-input [(ngModel)]="paramsChannelVo.name" (keyup)="getData(paramsChannelVo.name)" placeholder="系统名称" /> input的keyup事件把每次按键弹起都发送给了 getData() 方法。 这样一个绑定就造成了，每输入一个字符就会进行一次搜索，如果使用中文输入法，最后回车写入中文时，又有可能造成不会进行搜索 所以最好是能等到用户停止输入时才发送请求。此时就可以用到请求防抖（使用 RxJS 的操作符实现）。 二、如何使用防抖功能 1、component.js中引入 rxjs/Subject import {Subject} from 'rxjs/Subject'; import {debounceTime, distinctUntilChanged} from 'rxjs/operators'; 2、声明变量 private getDataTerms = new Subject<string>(); 这个string通常是[(ngModel)]绑定的值的类型 3、keyup绑定的getData方法 getData(value: string) { this.getDataTerms.next(value); } 4、请求防抖 ngOnInit():

一、前言 微前端(micro-frontends)是近几年在前端领域出现的一个新概念，主要内容是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。微前端的理念源于微服务，是将庞大的整体拆成可控的小块，并明确它们之间的依赖关系，而它的价值在于能将低耦合的代码与组件进行组合，基座+基础协议模式能接入大量应用，进行统一的管理和输出，许多公司与团队也都在不断尝试和优化相关解决技术与设计方案，为这一概念的落地和推广添砖加瓦。结合自身遇到的问题，适时引用微前端架构能起到明显的提效赋能作用。 二、背景 目前我司拥有大量的内部系统，这些系统采用相同的技术栈，在实际开发和使用过程中，逐渐暴露出如下几个问题： 1.有大量可复用的部分，虽然有组件库，但是依赖版本难统一； 2.静态资源体积过大，影响页面加载和渲染速度； 3.应用切换目前是通过链接跳转的方式实现，会有白屏和等待时长的问题，对用户体验不够友好； 针对上述几个问题，决定采用微前端架构对内部系统进行统一的管理，本文也是围绕微前端落地的技术预研方案。 三、方案调研 目前业界有多种解决方案，有各自的优缺点，具体如下： 路由转发：路由转发严格意义上不属于微前端，多个子模块之间共享一个导航即可 简单，易实现 体验不好，切换应用整个页面刷新； 嵌套 iframe：每个子应用一个 iframe 嵌套

实习 当年我还很愚昧，根本不知道很多大厂有实习招聘，直到大三要结束了，学校说: “同学们，你们大四没课，一定要实习啊！” 我才反应过来，喔，原来我要去找实习。 而且自己也从没规划过什么职业方向。我学的是软件工程，但我当时还真不知道自己未来的具体岗位。 安卓？IOS？我根本就没学过。 算法？学校的acm比赛上都没见过我的名字。 C++？大一的课程我早忘的烟消雾散了。 好像就Java Web还有些印象。 所以我实习时投的大多是java开发，当时学校组织了专门的实习招聘会。我晚上找了个自觉不错的简历模版，在招聘会时投简历。 我们的招聘会并没有一线大厂，大部分都是杭州的一些中小企业和创业公司。我当时还问负责招聘的老师: “老师老师，来咱学校的这些公司，有没有特别推荐的啊？” 老师: “阜博通不错。” 结果这家公司当天根本就没来，我回头又去阜博通网站投简历，也是石沉大海，当时觉得很惋惜。 有趣的是现在网上阜博通的口碑差的一逼。也不知道死没死，得亏当时也没去。 招聘会上大搜车也来了，当年大搜车刚从北京来杭州，还是刚创业阶段。我自己对车也比较喜爱，家里也有汽车相关的生意。 另外自己也喜欢创业公司，自觉加入创业公司，没多久说不定自己就是骨干员工，发家致富，指日可待。所以当时特中意大搜车，于是投了简历。 我还有好几个好朋友也投了搜车，后来我们也大多都被叫了过去面试。出乎意料的是，就我没过。

本文介绍Node.js的诞生史以及如何学习Node.js。 Node.js简史 从Node.js的命名上可以看到，Node.js的官方开发语言是JavaScript。之所以选择使用JavaScript，显然与JavaScript的开发人员多有关。总所周知，JavaScript是伴随着互联网的发展而火爆起来的，JavaScript也是前端开发人员必备的技能。同时，JavaScript也是浏览器能直接运行的脚本语言。 但也正是JavaScript在浏览器端的强势，导致了人们对于JavaScript的印象还停留在小脚本的角色，认为JavaScript只能干点前端展示的简单活。 直到Chrome V8引擎（ https://v8.dev/ ）的出现，让JavaScript彻底翻了身。Chrome V8是JavaScript渲染引擎，第一个版本随着Chrome浏览器的发布而发布（具体时间为2008年9月2日）。在运行JavaScript之前，相比其它的JavaScript的引擎转换成字节码或解释执行，Chrome V8将其编译成原生机器码（IA-32、x86-64、ARM或者MIPS CPUs），并且使用了如内联缓存等方法来提高性能。Chrome V8可以独立运行，也可以嵌入到C++应用程序中运行。 随着Chrome V8引擎的声名鹊起，在2009年，Ryan

一、为什么需要规范？ 无规矩不成方圆，编程也一样。 如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。 这时候，有人提出了何不统一标准，大家都按照这个标准来。于是 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。 Git Commit 规范可能并没有那么夸张，但如果你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。所以，严格遵守规范，利人利己。 二、具体规则 先来看看公式： <type>(<scope>): <subject> type 用于说明 commit 的类别，只允许使用下面7个标识。 feat：新功能(feature) fix：修补 bugdocs：文档(documentation) style： 格式(不影响代码运行的变动) refactor：重构(即不是新增功能，也不是修改bug的代码变动) test：增加测试 chore：构建过程或辅助工具的变动 scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。 subject 是 commit 目的的简短描述，不超过50个字符。 以动词开头，使用第一人称现在时，比如change

一、框架与组件 bootstrap等UI框架设计与实现 伸缩布局：grid网格布局 基础UI样式：元素reset、按钮、图片、菜单、表单 组件UI样式：按钮组、字体图标、下拉菜单、输入框组、导航组、面包屑、分页、标签、轮播、弹出框、列表、多媒体、警告 响应式布局：布局、结构、样式、媒体、javascript响应式 第三方插件：插件管理 jQuery、zepto使用原理以及插件开发 支持amd、cmd、全局变量的模块化封装 $.fn.method = function(){} mvc/mvvm框架原理设计，vue/angular/avalon等 directive设计：html、text、class、html、attr、repeat、ref，可扩展 filter设计：bool、upperCase、lowerCase，可扩展 表达式设计：if-else等实现 viewmodel结构设计：例如数据，元素，方法的挂载与作用域 数据更变检测：函数触发，脏数据检测、对象hijacking polymer/angular2思想与设计思路 import技术 template和script引入方式 css样式命名空间隔离 简单复用第三方库 reactjs原理与使用 virtual dom单向数据绑定 js执行语法方式 UI由状态控制 commonJS/AMD/CMD 模块引入 模块定义 模块标识

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

前端学不动的根本原因是目标感不强或者根本就没有目标。在学习前端之前，我们需要先思考我们要成为一个什么样前端工程师。接下来我们以时间线的方式，来告诉我们什么时间该做什么事儿。本文以普通人为例，也是想给普通人一些思路，结合自己的情况走出自己的路，超人请自行退出。 一、 1-3年（p5-p6） 这个时候大多数是应届生学习知识的积累期，对于前端三剑客：HTML/Javascript/CSS基础的夯实阶段。必看的书有《Javascript权威指南》/《Head First HTML and CSS, XHTML》/HTML方面多看看官方文档或者w3c的标准就成。另外这时候一般的前端工程师，会掌握一门应用级别框架（比如：React/Vue/Angular等等）。虽然使用传统三剑客我们也可以把任务完成，但是使用应用级别的框架还是会提高我们的效率，而且公司在人才招聘的时候应用级别的框架是必问的。不做赘述这个阶段感觉推不动的前端朋友建议推出，做自己更喜欢的事儿去吧。 本阶段关键词：（前端基础、原始积累、HTML/CSS/Javascript、Vue/React/Angular） 二、3-6年（p6-p7） 熬过艰难的初期阶段，接下来2-3年是一个差异化的体验期，在这个时间段通常情况下，前端工程师已经能够胜任所有的业务需求。可能大项目的拆解能力有所欠缺，但是这种能力会通过经验的积累不断积累有所上升

全文共1500字，预计学习时长6分钟 图源：unsplash 过去的三年我们都探讨了这个话题，那么今年的情况会是怎样呢？ 首先声明，此文并不是关于未来前端选择的比较，而是从三个方面（性能，大小，相似应用下的代码行数）来进行小范围的简单比较。 读者需要注意: · 本文是在比较Realworld软件——而不是正在研发中的软件，这些软件通常缺乏足够的知识和想法，因此难以实现。 · 由专家撰写或评审过——理想情况下，该技术领域的专家会评估此项目。 · 以某种方式标准化—— 一个符合特定规则的项目存在一种规范，提供后端API，静态标记和样式。 正在比较哪些库/框架？ 撰写此文时，Realworld存储库中有24种conduit实现As，它们之间的从属地位并不重要，唯一的判定标准是看它是否出现在RealWorld repo page上。 关注的是什么指标？ 性能—此应用程序需要多长时间才能显示内容并可用？ 大小—该应用程序有多大？我们将只比较已编译的JavaScript文件的大小。HTML和CSS对所有变体都是通用的，并且是从CDN（内容交付网络）下载的。所有技术都可以编译或转换为JavaScript，因此仅调整该文件的大小。 代码行数—需要多少行代码才能基于规范创建RealWorld应用程序？某些应用程序很麻烦，但应该不会产生重大影响。我们量化的唯一文件夹是每个应用程序中的src /