jingzhiMo
jingzhiMo
Hi, I want to create two queue in my process.But only the first queue created is useful.0 ``` js var kue = require('kue'); var queue2 = kue.createQueue({ redis: { post:...
在使用 vue 的时候，了解到计算属性很好用，可以延迟计算直到调用才返回真实的数据，而且计算属性依赖的值没有发生改变的情况，就不会重新执行函数计算；比较好奇是怎么实现的，但是没有去了解原理性相关，最近去看一下源码实现，大概直到具体的实现。下面就是根据自己的了解，手动实现一个简单的计算属性： ## 思考 我们知道 vue2.x 是基于`Object.defineProperty`来劫持数据的，那么挂载到`vm.data`的属性值就很好理解，在`getter`与`setter`的函数里面做一层简单的代理，那么计算属性为啥可以从一个函数变成一个数值，而且可以知道依赖的数据值？大概是因为计算属性的函数执行的时候，会触发到`data`属性的`getter`，那么我们就可以在这里做手脚，就知道当前的计算属性依赖了多少`data`数据了。 ## v1.0 我们来看一段的代码，声明`data`与`computed`数据，劫持`data`数据方法，初始化计算属性方法等 ```js // data 数据 var data = { foo: 123, bar: 'bar' } // data 的代理对象 var _data =...
## 背景 有运营同学反馈，在我们的系统上的用户信息不同步。在其他系统的用户信息会同步... ### 情况描述 这位运营同学有两种账号： * 个人账号 * 公共账号 通常来说，一般人都只有一个个人账号；但是运营需要切换为公共账号，使用该账号的权限来统一发布东西。而他遇到的情况就是，在系统 A 上从个人账号切换**公共账号**，然后打开我们的系统 B；发现系统 B 上看到的用户信息还是个人账号。而这个时候，他打开系统 C、D 看到的账号信息，却是**公共账号**。 上面说的A,B,C,D这些系统，都是由同一个后端应用来处理，每个系统的域名是一级域名相同，二级域名不同，例如： ```bash https://a.example.com https://b.example.com https://c.example.com https://d.example.com ``` ## 分析问题 ### 问题重现 我这边后面也申请了一个公共账号，也是按运营同学的执行步骤来执行：...
## 前言 这篇文章主要是调研 `module federation`的时候. 对 webpack 异步加载代码分割文件与加载远端组件的流程简述.前半部分是流程与部分代码分析, 后半部分是webpack代码的注释笔记. ## 介绍 Webpack 5 新增一个 `module federation` 的特性, 详情可以看 [官方文档](https://webpack.js.org/concepts/module-federation/). 这个特性大概的作用是: > 多个独立的构建可以组成一个应用程序，这些独立的构建之间不应该存在依赖关系，因此可以单独开发和部署它们。 > > 这通常被称作微前端，但并不仅限于此。 例如在 A 应用上运行的 组件 `FOO`...
最近在折腾一下微信公众号的开发，在这个过程中还是遇到挺多麻烦的事，当然，每一件麻烦的事情，在 goole 下都能找到对应的解决方案，这次是把整个过程记录一下，从开始到放弃。 这次文章的目标是，**在本地能够启动 node.js 服务，并能够接收用户发送给公众号的消息，进行响应处理。** ## 1. 申请公众号 (废话，下一个) ## 2. 搭建本地 node.js 开发 最开始的时候，是选中 koa 来作为本地开发的，因为研发手写的代码简单，就那么几行，就可以在一个完全空白的项目跑起来了。但是后面发现，koa虽简单，但是功能也比较简单，如果要进行完整的服务端开发，还需自己搭建非常多的内容。于是选中 egg 作为开发的框架。 ```bash # 下面命令是初始化 egg 相关项目，并启动 $ mkdir egg-example && cd...
最近在看一本比较经典的书《你的灯还亮着吗？》这本书讲述一些对问题的发现，还有对问题的定义等等。对问题的各个方面进行分析，分析的时候都带上生动的例子。下面是对书的一些语句进行摘录。 ## 摘录 * 对于想成为问题解决者的人来说，入门的关键在于把单一思维模式切换到多重思维模式。 * 问题是什么 * 谁碰到了问题 * 问题的本质是什么 * 问题就是理想状态和现实状态之间的差别 * 幻象问题是真实存在的问题 * 别去费力帮缺乏幽默感的人解决问题 * 不要把别人的解决方法作为定义问题的方法 * 如果你解决问题太过神速，别人根本不会相信你真的解决了问题 * 面对有利可图的问题时，道德考量很可能就烟消云散了 * 别把问题的解决方案当作问题的定义，当这个解决方案是由你提出的时候尤其如此 * 即使问题已经解决，你也无法确定你的问题定义是正确的 * 不要仓促下结论，但也不要忽视第一印象 *...
## 前言 这篇文章是Dan Abramov 在github上面的一个issue的讨论回答，虽然并不是一个正式发的文章，但是我觉得对于理解也是很重要，能够了解到设计的原因，这样子比大部分搜索到的“复制-粘贴”资料更深入。 原文链接[在这里](https://github.com/facebook/react/issues/11527#issuecomment-360199710)，大家有兴趣可以去看一下原版，以下是我渣渣英语的翻译： ## 正文 这里有几个想法，在某种意义上，这不是一个完整的回答，但仍然比不回答任何东西有帮助。 第一点，我认为我们为了批量更新而延迟调度(reconciliation)是很有利的。我们认同`setState`触发同步重新渲染在很多情况下是低效的，如果我们知道我们将要执行几个任务，那么批量更新是一个更好的选择。 举个例子，如果我们在浏览器点击的回调方法中，子组件(Child)与父组件(Parent)都调用了`setState`，我们不想去重新渲染两次子组件(Child)，而是去标识这两个组件都是脏的(dirty)，然后在退出浏览器事件(click)之前，把父子组件都重新渲染。 你提出一个问题：为什么我们不能够做同样的事情（批量更新），而是在调度(reconciliation)的最后来通过`setState`来马上更新`this.state`.我想目前没有一个明确的答案（两种解决方法（指同步和异步）都有权衡），但是下面是我想到的几个原因： ### 保证内部一致性(Guaranteeing Internal Consistency) 尽管`state`的更新是同步的，但是`props`不是（你不知道`props`值，除非你重新渲染父组件；如果使用同步的方法更新这些数据(译注：`props`和`state`)，批量更新就会超出处理窗口(batching goes out of the window)）。 现在React提供的对象`props`,`state`,`refs`,在它们互相看到是内部一致的。这样子就意味着，如果你只使用这些对象，这些对象数据能够根据调度树来保证互相对比（尽管这是一个旧版本的调度树）。为什么这样子做很重要？ 当你使用以下的`state`，如果它同步更新（正如你所想），这种模式是可行的： ```js console.log(this.state.value) // 0 this.setState({ value:...
最近在弄一个项目的模版，之前是以fork的方式新建；这种方式不太友好，所以想着参考cra，用cli的方式创建模版；也趁这个机会了解cra创建项目的过程。如果想了解概要过程，直接拉到页面底部即可。 ## 工具概览 先大概了解cra所用到的工具，在[入口文件](https://github.com/facebook/create-react-app/blob/master/packages/create-react-app/createReactApp.js)可以看到，下面写一些简单工具的简单描述与使用目的，对所使用工具熟悉，看源码起来会比较有帮助。熟悉的话可以跳过... ```js // chalk 是一个美化终端输出文字，通常可以更改文字的颜色与背景色 const chalk = require('chalk'); // commander 是一个对终端的参数输入进行处理工具，让输入参数更容易处理 const commander = require('commander'); // 原生 dns 模块，emm，作用就是对域名相关dns解析吧 const dns = require('dns'); // eninfo 获取系统的信息，设备信息，浏览器，node版本等；在debug的时候用到...
在之前一段时间中，我这边在补充 React 的技术栈（不会 React 都不好意思说自己搞前端了？）。下面分享一下我这边的学习的过程，还有一些学习过程中觉得不错的学习文章。主要是 React 技术栈与 Typescript 的应用。 ## 背景 在决定系统学习 React 的技术栈之前，其实对 React 的使用也有比较一些低层级的使用，所以是有一些比较浅的认识。因为也工作了不短时间了，在工作的工程中，在前端框架方面使用，前期是`ng1.x`，后面主用`vue`了。所以对前端框架的使用也是有一定经验。而对 Typescript 的使用，之前也有完整学习了一遍并做了一些简要的学习笔记。所以基于之前零散的学习，现在就开始系统学习一波吧，整理之前的知识。 ## 计划 先定个小目标，这次学习的目的是：系统整合 React 技术栈与 Typescript 的使用。 学习的载体：选一个自己熟悉项目，用这个项目来重构；或者选一个需求明确的产品。我觉得这个挺重要的，如果在开发过程中还要纠结各种需求问题，就与我们目标有偏移。我是选择了一个熟悉的产品并重构部分，一来可以反思之前的问题，二来因为熟悉需求，减少在上面耗费的其他精力。 开始需要列一下学习路线图`roadmap`，可能不需要很精确，主线清晰就ok了，学习的过程中有时候需要不断调整。下面是我这边前期的学习路线： 1. - [...
## 前言 最近在看一下`react-router`的源码，看到`react-rouer`的功能分散到几个`packages`，也依赖基础包`hisotry`，如果完整源码分析，可能会有点多，所以这次就弄一个张图来说明一下`react-router`的使用。估计再过一阵子，`v6`版本就要发了，这个图是`v5.x`版本的，有点悲催。下面直接上图，主要说是在浏览器端运行的`react-router`：  图有点点长，先来简单说一下不同颜色的区域表示什么： * 蓝色：使用的用户，也就是开发者 * 绿色：不同的组件 * 黄色：通常是指一些方法 * 橙色：创建对象的函数 * 白色：浏览器基础对象 左边纵向的一列： `react-router`,`react-router-dom`,`history`表示不同的库，而`window`就是浏览器。 下面就从对底层说起，捋一下这张图。 ## window 通常来说，路由库大部分基于两种： 一种是`window.history`对象来控制url的改变 另外一种是通过`location.hash`值来控制url的改变； 现在应该大部分都是用`window.history`，如果要兼容部分低版本浏览器，可能就需要到`location.hash`。而这两者都需要到`location`的支持，才能获取更详细的信息。 ## history 需要注意的是，这是一个库，并不是`window.history`的对象。 这个库是对页面路径的操作进行封装，目前是独立一个仓库，[github 地址](https://github.com/ReactTraining/history)，支持上面所说的`window.history`与`location.hash`的两种路由情况；...