ARTS-WEEK8(23.10.1-23.10.6)

Algorithm 一道算法题

防抖，截流，详见：https://leetcode.cn/problems/array-prototype-last/

//debouncing://We can think of it as a wait-and-see function. When we debounce a function, //we wait to see if the user carries out an action in a specified amount of time and if not, we’ll run the function. type timer = null | ReturnType<typeof setTimeout>type F = (...args: number[]) => voidfunction debounce(fn: F, t: number): F {    let timer:timer = null    return function(...args) {        if(timer) {            clearTimeout(timer)            timer = null        }        // timer = setTimeout(function(){        //     fn.call(this,...args)        //     // fn.apply(this, args)        // },t)        timer = setTimeout(()=>{          fn(...args)        },t)    }};

// We can think of throttle as a minimizing function; //it minimizes the number of calls made within a certain time interval.                            function throttle(fn, delay) {    let prev = Date.now();    return function() {        const context = this, args = arguments;        let now = Date.now();        if (now - prev >= delay) {            fn.call(context, args);            prev = now;        }    }}

Review 读一篇英文文章

Automate Your Coding Standard(detail:https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/thing_04/)

You've probably been there too. At the beginning of a project, everybody has lots of good intentions — call them "new project's resolutions." Quite often, many of these resolutions are written down in documents. The ones about code end up in the project's coding standard. During the kick-off meeting, the lead developer goes through the document and, in the best case, everybody agrees that they will try to follow them. Once the project gets underway, though, these good intentions are abandoned, one at a time. When the project is finally delivered the code looks like a mess, and nobody seems to know how it came to be this way.

你可能也经历过这种情况。在项目开始时，每个人都怀着很多好意，可以称之为“新项目的决心”。很多时候，这些决心都被写在文件中。关于代码的那些最终会成为项目的编码标准。在项目启动会议上，首席开发人员会浏览文件，最好的情况是，每个人都同意尽力遵守这些规定。然而，一旦项目开始进行，这些好意会逐个被抛弃。当项目最终交付时，代码看起来一团糟，似乎没有人知道它是如何变成这个样子的。

When did things go wrong? Probably already at the kick-off meeting. Some of the project members didn't pay attention. Others didn't understand the point. Worse, some disagreed and were already planning their coding standard rebellion. Finally, some got the point and agreed but, when the pressure in the project got too high, they had to let something go. Well-formatted code doesn't earn you points with a customer that wants more functionality. Furthermore, following a coding standard can be quite a boring task if it isn't automated. Just try to indent a messy class by hand to find out for yourself.

问题可能早在项目启动会议上就出现了。一些项目成员没有注意到。其他人没有理解重点。更糟糕的是，一些人表示不同意，并且已经在计划他们的编码标准反叛。最后，一些人明白了重点并同意了，但是当项目的压力变得太大时，他们不得不放弃一些东西。格式良好的代码并不能在客户需要更多功能的情况下为您赢得分数。此外，如果没有自动化，遵循编码标准可能会是一项相当乏味的任务。试着手动缩进一个混乱的类，您就会亲自体会到这一点。

But if it's such a problem, why is that we want to have a coding standard in the first place? One reason to format the code in a uniform way is so that nobody can "own" a piece of code just by formatting it in his or her private way. We may want to prevent developers using certain anti-patterns, in order to avoid some common bugs. In all, a coding standard should make it easier to work in the project, and maintain development speed from the beginning to the end. It follows then that everybody should agree on the coding standard too — it does not help if one developer uses three spaces to indent code, and another one four.

但如果这是一个问题，为什么我们要首先制定编码标准呢？制定统一的代码格式的一个原因是，这样就没有人可以通过以自己的私有方式格式化代码来"拥有"代码的一部分。我们可能希望防止开发人员使用某些反模式，以避免一些常见的错误。总之，编码标准应该使项目中的工作更容易，并从开始到结束保持开发速度。因此，每个人都应该对编码标准达成一致意见 —— 如果一个开发人员使用三个空格来缩进代码，而另一个开发人员使用四个，这是没有帮助的。

There exists a wealth of tools that can be used to produce code quality reports and to document and maintain the coding standard, but that isn't the whole solution. It should be automated and enforced where possible. Here are a few examples:

• Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code.

• Use static code analysis tools to scan the code for unwanted anti-patterns. If any are found, break the build.

• Learn to configure those tools so that you can scan for your own, project-specific anti-patterns.

• Do not only measure test coverage, but automatically check the results too. Again, break the build if test coverage is too low.

有很多工具可以用来生成代码质量报告，以及记录和维护编码标准，但这并不是整个解决方案。应该在尽可能的情况下自动化并强制执行。以下是一些示例：

• 确保代码格式化是构建过程的一部分，以便每次编译代码时都会自动运行。

• 使用静态代码分析工具扫描代码以查找不需要的反模式。如果发现任何反模式，就中断构建过程。

• 学会配置这些工具，以便可以扫描项目特定的反模式。

• 不仅要衡量测试覆盖率，还要自动检查结果。同样，如果测试覆盖率过低，就中断构建过程。

Try to do this for everything that you consider important. You won't be able to automate everything you really care about. As for the things that you can't automatically flag or fix, consider them to be a set of guidelines supplementary to the coding standard that is automated, but accept that you and your colleagues may not follow them as diligently.

尝试将这一原则应用于您认为重要的所有方面。您可能无法自动化您真正关心的一切。至于那些无法自动标记或修复的事情，可以将它们视为编码标准的补充准则，该编码标准是自动化的，但也要接受您和您的同事可能不会如此认真地遵守它们。这些补充准则可以在项目中提供一些灵活性，以便更好地适应特定情况和需求。

Finally, the coding standard should be dynamic rather than static. As the project evolves, the needs of the project change, and what may have seemed smart in the beginning, isn't necessarily smart a few months later.

最后，编码标准应该是动态的而不是静态的。随着项目的发展，项目的需求也会发生变化，最初可能看似明智的做法在几个月后不一定还是明智的做法。

Technique/Tips 分享一个小技术

Why useState() hook returns array and not object

因为函数组件中可以多次使用 useState/useReducer，可以定义多个不同 state，数组可以一次返回 state、setState，命名交给用户自定义。如果是对象再解构，那么 state 的命名就要写死了，用户想定义多个 state 的时候，还得自己改写名字，太麻烦了。

// 自定义hookimport { useState, useEffect } from "react";
export default function useStoreInput(storageKey) {  const [value, setValue] = useState(    JSON.parse(localStorage.getItem(storageKey)) ?? ""  );
  useEffect(() => {    localStorage.setItem(storageKey, JSON.stringify(value));  }, [value, storageKey]);
  return [value, setValue];}
// 引用自定义hook组件import React from "react";import useStoreInput from "./useStoreInput";
const Form = () => {  const [name, setName] = useStoreInput("name");  const [email, setEmail] = useStoreInput("email");
  return (    <form>      <input type="text" value={name} onChange={e => setName(e.target.value)} />      <input        type="text"        value={email}        onChange={e => setEmail(e.target.value)}      />      <button>Register</button>    </form>  );};
export default Form;


//如果使用对象import React from "react";import useStoreInput from "./useStoreInput";// So every time I use the hook I'd tell it to rename value and setValue with new names.const Form = () => {  const { value: name, setValue: setName } = useStoreInput("name");  const { value: email, setValue: setEmail } = useStoreInput("email");
  return (    <form>      <input type="text" value={name} onChange={e => setName(e.target.value)} />      <input        type="text"        value={email}        onChange={e => setEmail(e.target.value)}      />      <button>Register</button>    </form>  );};
export default Form;

This is exactly why useState() hook returns array and not object

Share 分享一个观点

学习设计模式最主要的不是学习模式，而是理解设计模式的原则，理解要怎么样才能做出架构优秀的程序。

设计模式

• 单例模式

• 原型模式

• 工厂模式

• 抽象工厂模式

• 建造者模式

• 代理模式

• 适配器模式

• 桥接模式

• 装饰模式

• 外观模式

• 享元模式

• 组合模式

• 模板方法模式

• 策略模式

• 命令模式

• 职责链模式

• 状态模式

• 观察者模式

• 中介者模式

• 迭代器模式

• 访问者模式

• 备忘录模式

• 解释器模式

Design Patterns 这本书设计是 1995 年，基于 Java 这门语言的类型系统，集成系统，接口模型等，许多模式直接搬到 JaveScript 中的直接使用的非常少，在前端领域中，我们比较熟悉的是观察者模式和外观模式。

观察者模式

在 node 的 EventEmitter，例如 process 是基于 EventEmitter 的一个实例，处理从 C++中抛出的事件。

在 DOM 的 addEventListener。观察者模式解决什么问题呢？解决对象与对象之间的通讯问题。

外观模式

前端中比较常见的是 jQuery，例如 jQuery 中事件的注册。

$("button").on({	click:function(){		console.log("click")	},	mouseover:function(){		console.log("mouseOver")	}});

内部隐藏了对各个浏览器的兼容，对外直接暴露 callback 方法。

外观模式解决了什么问题呢？兼容性问题

设计模式的六大原则：

• 单一职责原则

• 里氏替换原则

• 依赖倒转原则

• 接口隔离

• 最小知晓原则

• 开闭原则

单一职责，近前比较流行的前端框架，React,Vue 中的组建设计，实现重用。还有微前端，实现分而治之，例如各自迭代等。

开闭原则：对扩展开放，对修改关闭。如前端开发中的 webpack 的 loader,css-loader,ts-loader 等。