Storybook is a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test components. [https://storybook.js.org/static/storybook-intro.5eb59c13.gif] 2018年10月storybook发布了4.0版本，在UI层支持、构建、移动端、stroy参数等多个方面进行了升级优化。本文已React的UI组件为例，演示如何新建/集成Storybook到项目中，并对UI组件进行全方位的管理，包括发布、demo文档、测试等。 1. 新建一个STORYBOOK REACT项目 * 按照官方教程使用 npx -p @storybook/cli sb init 安装，一直会报错：

RPC 架构初探 RPC的全称是Remote Procedure Call，它是一种进程间的通信方式。允许像调用本地服务一样调用远程服务，它的具体的实现方式可以不同，例如Spring的HTTP Invoker，FaceBook的Thrift二进制私有协议通信。 RPC概念术语在上世纪80年代由Bruce Jay Nelson提出，在他的论文中对RPC进行了如下的总结： * 简单：RPC概念的语义十分清晰和简单，这样建立分布式计算就更容易。 * 高效：过程调用看起来十分简单并且高效。 * 通用：在单机计算中过程往往是不同算法和API，跨进程调用最重要的是通用的通信机制。 2006年之后，随着移动互联网的发展，各种智能终端的普及，远程分布式调用已经成为主流，RPC框架也如雨后春笋搬诞生，开源和自研的RPC框架的普及标志着传统垂直应用架构时代的终结。

原文地址： http://codewinsarguments.co/git-submodules-vs-git-subtrees/ 当开发人员开始使用Git时，他们遇见的首要问题是处理当前项目的submodules。近期我打算用subtrees迁移所有项目，但看起来没那么简单。接下来我会解释一下为什么。 为什么使用SUBMODULES OR SUBTREES? 每个团队都应该有公共的代码项目，submodule和subtrees可以让我们在不同项目中使用这些公共的代码，避免因复制产生重复代码，甚至导致相同代码出现不同修改产生多个版本。 SUBTREES VS SUBMODULES 最简单理解两者的方式，subtrees在父仓库是拉取下来的一份子仓库拷贝，而submodule则是一个指针，指向一个子仓库commit。

operation transform了解一下？ 协同文档的技术实现 dekuchen 2018.6 1984 年，MIT 的科学家提出了计算机支持的协同工作（Computer Supported Cooperative Work，缩写为 CSCW），使得人们可以借助计算机和互联网去完成协同工作。比如利用用于文档编辑的 Wikis 和用于编程的版本控制系统，小组成员可以在世界任意角落去共同编写大型的百科全书或软件系统 协同文档现在貌似有很多公司陆续实现了，例如最早的 Google、国内的石墨文档、腾讯的腾讯文档等等。 虽然在使用中看似很简单，但是实际上这个协同文档的技术实现有很多需要注意的地方。对于公司来说，由于员工较多，而且一般 leader 具有较高工程能力，对他们来说不是什么很困难的事情。但是即使这样，Google 办公套件至少用了两年时间才使他们的协同系统成熟。 这里我简单的跟大家分享一下，协同文档的技术实现的其中一个方式，也是最具有普遍意义的方式，可以协同任何数据结构。

优秀的团队必不可缺少源代码的质量管理，比如eslint、sasslint等代码检测工具，借助git hook能力，我们可以将这些工具无缝地整合到git开发工作流中。 GIT HOOK介绍 Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur Git hook能够在发生某特定行为的时机，触发执行自定义的脚本。 GIT HOOK分类 Git hook分为客户端hooks（Client-Side Hooks）和服务端hooks（Server-Side Hooks），下面列出了所有可以触发hook的时机，可以在 官方文档 [https://git-scm.com/docs/githooks] 中查询： * Client-Side Hooks * pre-commit: 执行 git commit 命令时触发，常用于检查代码风格

本文作者：IMWeb howenhuo 原文出处： IMWeb社区 未经同意，禁止转载 常见 REDUCER 冗余 在使用 Redux 开发应用的过程中，我们经常会复制黏贴一些相似的 reducer 举个例子，有两个页面，它们都包含一个数据列表，它们都含有相同的状态 const page1State = { loading: false, // 列表加载态（菊花） retcode: 0, // 列表CGI返回码 page: 0, // 列表当前页码 count: 10, // 列表每页数量 pageTotal: 0, // 订单列表总共分页数量list: [], // 列表 sort: -1// 倒叙排序 }; const page2State = { loading: false, // 列表加载态（菊花） retcode: 0, // 列表CGI返回码 page: 0, // 列表当前页码 count: 10, // 列表每页数量

是什么 代理模式是为一个对象提供一个代用品或占位符，以便控制对它的访问。 生活是一切东西的起源，在生活中也到处能看到代理模式的影子。 明星有经纪人作为代理，要联系明星的档期其实是和经纪人联系，经纪人联系好之后，再有明星负责签约、演出。 想想平时工作中也有这种例子，每个小组都要发周报，组长负责周报的收集， 总监通过周报查看每个成员的工作情况，而不是每个成员都直接向总监汇报。 甚至古代也能找到类似的例子，挟天子以令诸侯，曹操和汉献帝的关系，也有代理模式的影子。 为什么 大概对代理模式有个模糊的概念了，那为什么要存在代理模式？ 单一职责原则 想一想，明星为什么要有经纪人。经纪人可以负责帮助明星安排各种工作，对明星包装炒作等等。而明星自己只专注于演出。如果所有工作都交给明星自己完成，一个再高效再厉害的人估计也得忙疯了。 相应的，在面向对象设计原则中有单一职责原则，它规定一个类应该只有一个发生变化的原因。如果一个类承担了太多职责，这个类就会变得越来越庞大，难以维护。 对象无法被直接操作

写在前面 作为一个互联网前端老鸟，这么些年下来，做过的项目也不少。从最初的 我的QQ中心 、 QQ圈子 ，到后面的 QQ群项目 、 腾讯课堂 。从几个人的项目，到近百号人的项目都经历过。 这期间，实现了很多的产品需求，也积累了一些经验。这里稍作总结，希望能给新入行的前端小伙伴们一些参考。 做好需求的关键点 要说如何做好一个需求，展开来讲，可以写好几篇文章，这里只挑重点来讲。 最基本的，就是把握好 3W ：what、when、how。 * what ：做什么？ * when ：完成时间？ * how ：如何完成？ 需求场景假设 为了下文不至于太过枯燥，这里进行需求场景的模拟，下文主要围绕这个“需求”，从what、when、how 三个点展开来讲。 假设现在有个论坛的项目，产品经理小C提了个需求 “给论坛增加评论功能” 。作为 前端工程师 的小A接到需求后，该如何高质量的完成这个需求。 * 项目名称：兴趣论坛。 * 项目组主要成员：前端工程师小A，后台工程师小B，产品经理小C。 * 产品需求：给论坛增加评论功能。 备注：此时我们脑海里浮现的应该是下面这张图。

有人说产品开发过程中web前端没有结论，只有随需求不停的修改，但是项目必须要有阶段性的结论，作为一个前端开发，如何避免为了某一个需求而陷入反复更改的困境呢？不要把责任全部推到产品不断的需求更改或者设计不停的视觉调整上，你其实可以做得更好。在不断的追求新技术，打磨技术精益求精之时，拓宽自己的知识面，寻找正确了工作姿势也很重要。 -------------------------------------------------------------------------------- 首先，心态很重要。

{{tags: 工具建设 开发模式}} 序言 相信很多程序员都会经历两件事：第一件事情是没日没夜加班撸代码；第二件事情是写的程序出现bug没有及时发现而被老板骂。不知道大家有木有考虑从工具或者架构的角度出发去解决以上两个问题，木有考虑的同学也木有关系，本系列文章将会将会围绕整个前端的开发流程出发解决这两个问题，帮助大家提高产品质量以及开发效率。 文章导航图 对于前端开发来说大致分为5个阶段：开发、联调、测试、上线、监控维护，本系列文章将会选取每个阶段比较影响效率以及质量的点进行详细描述。这一章我们先来从开发阶段出发考虑有哪些方面可以做效率提升？ 页面结构继承化

5月7日，为期1天的匠心 · 打造：腾讯SNG&msup技术开放日圆满结束。本次开放日是腾讯 SNG和 msup 联合举办，通过案例分享的形式展示了社交网络事业群产品（包括 QQ、QQ 音乐等）背后的十几年的技术沉淀与积累，全景解读了拥有亿级用户规模的SNG 的技术实践。 稍显粗犷的身材，配上一张娃娃脸，加上温柔细腻的嗓音，IMWeb的又一萌属性 男神莫卓颖 在7日的开放日 前端专场 上给我们带来了一场干货分享：《如何搭建高质量、高效率的前端工程体系》。 他介绍了前端如何从开发、链条、测试、上线、监控维护五个阶段是如何做效率提升的，着重介绍了围绕整个前端的自动化如何提升效率。

前端需要知道的 依赖注入(DEPENDENCY INJECTION, DI) 1. 前言 XX库实现了依赖注入，哇塞，好牛X呀~~~ 切，依赖注入的实现那么简单，不就一个map + 函数参数解析而已吗？ 可是，你真的了解 依赖注入(Dependency Injection, DI) 吗？ 本文将详细解释什么是依赖注入，并解释属于前端的依赖注入 注意 1. 本文专门为前端同学解释什么是依赖注入，文中例子也是js，非前端同学可以选择绕道 2. 已经知道依赖注入的同学也可以绕道 2. 什么是 依赖注入 2.1. 它是模式 首先，依赖注入是一个设计模式，因为它解决的是一类问题 2.2. 理解它的作用域 要知道依赖注入是解决什么问题，最好先了解一个原则： 依赖倒转原则(Dependence Inversion Priciple, DIP) 提倡： 1. 高层模块不应该依赖低层模块。两个都应该依赖抽象 2. 抽象不应该依赖细节，细节应该依赖抽象 3. 针对接口编程，不要针对实现编程 在编程时，我们对系统进行模块化，它们之间有依赖，比如模块A依赖模块B