效果演示

横版

竖版

思路分析

基本结构

HTML基本结构

<div id="container"></div>

这里只需要一个容器，其他的结构通过js动态生成

CSS

#container {

  /* 添加这行样式=>文字纵向从右往左显示 */

  /* 目前先不设置,后面可以取消注释 */

  /* writing-mode: vertical-rl; */

}

#container span {

  /* 这里opacity先设置为1，让其不透明，可以看到每一步的效果 */

  /* 写完js之后到回来改为0 */

  opacity: 1;

  transition: opacity 0.5s;

}

文本数据

const data = ['清明时节闹坤坤，', '路上行人梳中分；', '借问荔枝何处有，', '苏珊遥指蔡徐村。']

使用数组存放文本数据，一个元素代表一段文字

创建p标签

使用for/of循环遍历数组创建对应个数的p标签，添加到html页面中

const data = ['清明时节闹坤坤，', '路上行人梳中分；', '借问荔枝何处有，', '苏珊遥指蔡徐村。']

// 获取dom元素

const container = document.querySelector('#container')

// for/of循环遍历数组

for (const item of data) {

  // 打印每一个item => 数组的每一个元素

  console.log(item)

  // 创建p标签

  const p = document.createElement('p')

  // 将p标签插入到container

  container.append(p)

}

item代表数组的每一个元素，也就是每一段文字，所以会创建4个p标签

与数组元素数量对应的p标签就生成好了

接下来就是将每一个元素里面的文本添加到span标签中

创建span标签

为每一个字创建一个span标签，然后让span标签的内容等于对应的字，再将每一个生成的span插入到p标签

本节代码

// 遍历item的每一个字

for (let i = 0; i < item.length; i++) {

  // 创建span

  let span = document.createElement('span')

  // span的内容等于item的每一个字

  span.innerHTML = item[i]

  // 将span插入到p标签中

  p.append(span)

}

合并后代码

const data = ['清明时节闹坤坤，', '路上行人梳中分；', '借问荔枝何处有，', '苏珊遥指蔡徐村。']

// 获取dom元素

const container = document.querySelector('#container')

// for/of循环遍历数组

for (const item of data) {

  // 打印每一个item => 数组的每一个元素

  console.log(item)

  // 创建p标签

  const p = document.createElement('p')

  // 遍历item的每一个字

  for (let i = 0; i < item.length; i++) {

    // 创建span

    let span = document.createElement('span')

    // span的内容等于item的每一个字

    span.innerHTML = item[i]

    // 将span插入到p标签中

    p.append(span)

  }

  // 将p标签插入到container

  container.append(p)

}

此时已经完成了渲染数组，并将数组的每一个元素的文字渲染到单独的span中

接下来就要让每一个文字做到从看不见到看的见的效果

添加透明度过渡效果

将css样式中的opacity由1改为0

因为每个字的出现时间不一样，所以不能直接在循环的时候直接添加过渡效果，添加以下代码，让span标签在添加到p标签前也添加到新数组中

const arr = []

// 将span也添加到新数组中

arr.push(span)

最后遍历arr数组，为每一个元素添加一个过渡延迟效果

// 延时1毫秒等待上方循环渲染完成

setTimeout(() => {

  // 遍历arr数组的每一个元素

  arr.forEach((item, index) => {

    // 给每一个元素添加过渡延迟属性

    item.style.transitionDelay = `${index * 0.2}s`

    // 将透明度设置为不透明

    item.style.opacity = 1

  })

}, 1)

最后的最后将css样式中的opacity改为0，让所有的字透明

#container span {

  opacity: 0;

  transition: opacity 0.5s;

}

完整js代码

const data = ['清明时节闹坤坤，', '路上行人梳中分；', '借问荔枝何处有，', '苏珊遥指蔡徐村。']

const arr = []

// 获取dom元素

const container = document.querySelector('#container')

// for/of循环遍历数组

for (const item of data) {

  // 打印每一个item => 数组的每一个元素

  console.log(item)

  // 创建p标签

  const p = document.createElement('p')

  // 遍历item的每一个字

  for (let i = 0; i < item.length; i++) {

    // 创建span

    let span = document.createElement('span')

    // span的内容等于item的每一个字

    span.innerHTML = item[i]

    // 将span插入到p标签中

    p.append(span)

    // 将span也添加到新数组中

    arr.push(span)

  }

  // 将p标签插入到container

  container.append(p)

}

// 延时1毫秒等待上方循环渲染完成

setTimeout(() => {

  // 遍历arr数组的每一个元素

  arr.forEach((item, index) => {

    // 给每一个元素添加过渡延迟属性

    // 让每一个字都比前一个字延时0.2秒的时间

    item.style.transitionDelay = `${index * 0.2}s`

    // 将透明度设置为不透明

    item.style.opacity = 1

  })

}, 1)

至此，已经完成了逐字显示的效果，最后介绍一个css属性

writing-mode

使用这个属性可以改变文字方向，实现纵向从左往右或从右往左显示

以下摘自mdn文档

writing-mode 属性定义了文本水平或垂直排布以及在块级元素中文本的行进方向。为整个文档设置该属性时，应在根元素上设置它（对于 HTML 文档，应该在 html 元素上设置）

horizontal-tb

对于左对齐（ltr）文本，内容从左到右水平流动。对于右对齐（rtl）文本，内容从右到左水平流动。下一水平行位于上一行下方。

vertical-rl

对于左对齐（ltr）文本，内容从上到下垂直流动，下一垂直行位于上一行左侧。对于右对齐（rtl）文本，内容从下到上垂直流动，下一垂直行位于上一行右侧。

vertical-lr

对于左对齐（ltr）文本，内容从上到下垂直流动，下一垂直行位于上一行右侧。对于右对齐（rtl）文本，内容从下到上垂直流动，下一垂直行位于上一行左侧。

一. 目标效果

二. 实现思路

使用Animate API或者CSS动画的方式都可以，我选择的是Animate API。

实现无缝滚动的一般思路

Translate位移+无限循环动画。但是这样会有一个小问题，就是在动画结束又开始的一瞬间会闪烁一下，不是很完美。

解决方法

复制一份数据, 原来的1份数据变成2份数据。然后动画的关键帧设置位移的终点为50%，这样每次动画的结束帧就在数据的中间位置, 注意如果数据之间有间距的话，还要加上间距的一半。这样即可实现无限滚动，并且足够丝滑。3

三. 实现

核心代码

以下代码示例都使用React框架。

  // 使用Web animate Api 添加动画

  useEffect(() => {

    if (!container.current) return;

    // 获取gap值

    const gap = getComputedStyle(container.current).gap.split('px')[0] ?? 0;



    // 滚动容器(container)的50%宽度 + 滚动容器的50%gap值

    // 如果不加滚动容器的50%gap值, 在动画结束又开始的瞬间会跳一下

    const translateX = container.current.clientWidth / 2 + Number(gap) / 2;

    if (isNaN(translateX)) {

      throw new Error('translateX is NaN!');

    }



    // 定义关键帧, 执行动画

    let keyframes: Keyframe[] = [];

    if (type === 'rtl') {

      keyframes = [

        {

          transform: 'translateX(0)',

        },

        {

          transform: `translateX(-${translateX}px)`,

        },

      ];

    } else if (type === 'ltr') {

      keyframes = [

        {

          transform: `translateX(-${translateX}px)`,

        },

        {

          transform: 'translateX(0)',

        },

      ];

    }



    animation.current = container.current.animate(keyframes, {

      duration,

      easing: 'linear',

      iterations: Infinity,

    });

  }, []);



 return (

    // 使用context传递store和dispatch

    <SwiperContext.Provider value={{ store, dispatch }}>

      <div className={classNames(['w-full overflow-x-hidden', wrapperClassName])}>

        {/* 使用inline-flex代替flex，让ul的宽度被子元素撑开 */}

        <ul

          className={classNames(['inline-flex flex-nowrap gap-5', className])}

          style={style}

          ref={container}

        >

          {/* 类似于HOC的效果, 为Item组件添加_key */}

          {children.map((child) =>

            cloneElement(child as ReactElement, {

              _key: (child as ReactElement).key ?? '',

            })

          )}



          {/* 实现无缝滚动, 复制一组子元素进行占位 */}

          {children.map((child) =>

            cloneElement(child as ReactElement, {

              _key: (child as ReactElement).key ?? '',

            })

          )}

        </ul>

      </div>

    </SwiperContext.Provider>

  );

其中type只是为了区分在x轴上的滚动方向而已，根据方向应用不同的动画。动画的实例使用useRef()去保存。
方便后续调用此动画实例进行动画的暂停和播放。

完整代码

SwiperBox.tsx

import { useHover } from 'ahooks';

import classNames from 'classnames';

import { isNaN, isUndefined } from 'lodash-es';

import {

  cloneElement,

  CSSProperties,

  ReactElement,

  ReactNode,

  useContext,

  useEffect,

  useRef,

} from 'react';



import { SwiperContext } from './swiper-context';

import useSwiperReducer, { SwiperActions } from './use-swiper-reducer';



interface SwiperBoxProp {

  /**

   * 轮播方向

   *

   * @type {('ltr' | 'rtl')}

   * @memberOf SwiperBoxProp

   */

  type: 'ltr' | 'rtl';



  /**

   * 子节点

   *

   * @type {ReactNode[]}

   * @memberOf SwiperBoxProp

   */

  children: ReactNode[];



  /**

   * 类名

   *

   * @type {string}

   * @memberOf SwiperBoxProp

   */

  className?: string;



  /**

   * 外层节点类名

   *

   * @type {string}

   * @memberOf SwiperBoxProp

   */

  wrapperClassName?: string;



  /**

   * 节点样式

   *

   * @type {CSSProperties}

   * @memberOf SwiperBoxProp

   */

  style?: CSSProperties;



  /**

   * 动画持续时间

   *

   * @type {EffectTiming['duration']}

   * @memberOf SwiperBoxProp

   */

  duration?: EffectTiming['duration'];



  /**

   * 鼠标悬停时触发

   * @type {boolean} isHovering 是否悬停

   * @type {string} key 节点key

   *

   * @memberOf SwiperBoxProp

   */

  hoverOnChange?: (isHovering: boolean, key: string) => void;

}



/**

 * 无限循环、无缝轮播组件

 * 使用这个组件必须通过gap的方式(eg: gap-4)来设置滚动项之间的距离, 不能使用margin的方式, 不然无缝滚动会有问题

 */

function SwiperBox(prop: SwiperBoxProp) {

  const {

    type,

    className,

    wrapperClassName,

    style,

    children,

    duration = 3000,

    hoverOnChange,

  } = prop;

  const [store, dispatch] = useSwiperReducer();

  const { activeKey } = store;

  // 滚动容器

  const container = useRef<HTMLUListElement>(null);

  // 动画实例

  const animation = useRef<Animation | null>(null);



  // activeKey改变时通知外部组件

  useEffect(() => {

    hoverOnChange &&

      !!Object.keys(activeKey).length &&

      hoverOnChange(activeKey.isHovering, activeKey.key);

  }, [activeKey]);



  // 获取所有的key值并存储

  useEffect(() => {

    dispatch(

      SwiperActions.updateKeys(children.map((child) => (child as ReactElement).key ?? ''))

    );

  }, []);



  // 使用Web animate Api 添加动画

  useEffect(() => {

    if (!container.current) return;

    // 获取gap值

    const gap = getComputedStyle(container.current).gap.split('px')[0] ?? 0;



    // 滚动容器(container)的50%宽度 + 滚动容器的50%gap值

    // 如果不加滚动容器的50%gap值, 在动画结束又开始的瞬间会跳一下

    const translateX = container.current.clientWidth / 2 + Number(gap) / 2;

    if (isNaN(translateX)) {

      throw new Error('translateX is NaN!');

    }



    // 定义关键帧, 执行动画

    let keyframes: Keyframe[] = [];

    if (type === 'rtl') {

      keyframes = [

        {

          transform: 'translateX(0)',

        },

        {

          transform: `translateX(-${translateX}px)`,

        },

      ];

    } else if (type === 'ltr') {

      keyframes = [

        {

          transform: `translateX(-${translateX}px)`,

        },

        {

          transform: 'translateX(0)',

        },

      ];

    }



    animation.current = container.current.animate(keyframes, {

      duration,

      easing: 'linear',

      iterations: Infinity,

    });

  }, []);



  // 鼠标移入动画暂停/播放

  useEffect(() => {

    if (!animation.current) return;

    if (isUndefined(activeKey.isHovering)) return;



    if (activeKey.isHovering) {

      animation.current.pause();

    } else {

      animation.current.play();

    }

  }, [activeKey]);



  return (

    // 使用context传递store和dispatch

    <SwiperContext.Provider value={{ store, dispatch }}>

      <div className={classNames(['w-full overflow-x-hidden', wrapperClassName])}>

        {/* 使用inline-flex代替flex，让ul的宽度被子元素撑开 */}

        <ul

          className={classNames(['inline-flex flex-nowrap gap-5', className])}

          style={style}

          ref={container}

        >

          {/* 类似于HOC的效果, 为Item组件添加_key */}

          {children.map((child) =>

            cloneElement(child as ReactElement, {

              _key: (child as ReactElement).key ?? '',

            })

          )}



          {/* 实现无缝滚动, 复制一组子元素进行占位 */}

          {children.map((child) =>

            cloneElement(child as ReactElement, {

              _key: (child as ReactElement).key ?? '',

            })

          )}

        </ul>

      </div>

    </SwiperContext.Provider>

  );

}



interface SwiperBoxItemProp {

  children: ReactNode;

  // 唯一标识, React不会将key转发到组件中, 因此自定义一个唯一的_key

  _key?: string;

}



function SwiperBoxItem(prop: SwiperBoxItemProp) {

  const { children, _key } = prop;



  const container = useRef<HTMLLIElement>(null);

  const context = useContext(SwiperContext);



  // 鼠标hover

  const onEnter = () => {

    context && _key && context.dispatch(SwiperActions.onEnter(true, _key));

  };



  // 鼠标退出hover

  const onLeave = () => {

    context && _key && context.dispatch(SwiperActions.onLeave(false, _key));

  };



  useHover(container, {

    onEnter,

    onLeave,

  });



  return (

    <li

      ref={container}

      className="transition-transform duration-500 ease-out hover:scale-105"

    >

      {children}

    </li>

  );

}



const SwiperWithAnimation = {

  Box: SwiperBox,

  Item: SwiperBoxItem,

};



export default SwiperWithAnimation;

swiper-context.ts

import { createContext, Dispatch } from 'react';



import { SwiperAction, SwiperState } from './use-swiper-reducer';



export type SwiperContextType = {

  store: SwiperState;

  dispatch: Dispatch<SwiperAction>;

};

export const SwiperContext = createContext<SwiperContextType | null>(null);

useSwiperReducer.ts

import { useReducer } from 'react';



export interface SwiperState {

  activeKey: { isHovering: boolean; key: string };

  totalKeys: string[];

}



export type SwiperAction<T = any> = {

  type: string;

  payload: T;

};



export const SwiperActions = {

  onEnter: (isHovering: boolean, key: string) => ({

    type: 'onEnter',

    payload: { isHovering, key },

  }),

  onLeave: (isHovering: boolean, key: string) => ({

    type: 'onLeave',

    payload: { isHovering, key },

  }),

  updateKeys: (keys: string[]) => ({

    type: 'update_keys',

    payload: keys,

  }),

};



export default function useSwiperReducer() {

  const initialState: SwiperState = {

    activeKey: {} as SwiperState['activeKey'],

    totalKeys: [] as SwiperState['totalKeys'],

  };



  const reducer = (store: SwiperState, { type, payload }: SwiperAction): SwiperState => {

    switch (type) {

      case 'onEnter':

        return {

          ...store,

          activeKey: payload,

        };

      case 'onLeave':

        return {

          ...store,

          activeKey: payload,

        };

      case 'update_keys':

        return {

          ...store,

          totalKeys: payload,

        };

      default:

        return store;

    }

  };



  const [store, dispatch] = useReducer(reducer, initialState);



  return [store, dispatch] as const;

}

四、如何使用

import SwiperWithAnimation from '@/components/swiper-box/SwiperBox';

import { uniqueId } from 'lodash-es';





const DATA = new Array(2).fill(0).map(() => uniqueId('data'));

/**

 *  测试页面

 */

export default function TestPage() {

  // 鼠标hover事件

  const hoverOnChange = (isHovering: boolean, key: string) => {

    console.log('isHovering: ', isHovering);

    console.log('key: ', key);

  };



  return (

    <div>

      <SwiperWithAnimation.Box

        type="ltr"

        wrapperClassName="py-9 m-auto !w-[600px] border border-red-200"

        className="gap-8"

        hoverOnChange={hoverOnChange}

      >

        {DATA.map((data) => (

          <SwiperWithAnimation.Item key={data}>

            <div className="f-c h-[300px] w-[300px] rounded-lg bg-theme-primary">

              <div className="text-2xl">{data}</div>

            </div>

          </SwiperWithAnimation.Item>

        ))}

      </SwiperWithAnimation.Box>

    </div>

  );

}

最近项目上要实现一个小 'x' 的关闭样式, 今天记录一下处理过程

先看效果

HTML DOM 元素说明

要渲染内容必须有 dom 节点, 这里我们使用 span 作为容器, 然后所有的处理都基于它进行处理

<span class="close-x">span>

第一步, 设置 close-x 的样式

@closeXSize: 20px; // 大小/尺寸

@closeXLine: 2px; // 线条宽度

.close-x {

    position: relative;

    display: inline-block;

    width: @closeXSize;

    height: @closeXSize;

    cursor: pointer;

}

• 通过使用 closeXSize closeXLine, 方便对尺寸进行调整
  
  渲染出来大概是这样的
  

第二步, 通过伪元素 before after 画两条线

.close-x {

    // ...



    &::before, &::after {

        position: absolute;

        left: 50%;

        width: @closeXLine;

        height: 100%;

        margin-left: (@closeXLine / -2);

        content: '';

        background: #000;

    }

}

• margin-left 的设置是为了处理'线'的自身宽度
  
  渲染出来大概是这样的
  

第三步, 分别设置旋转角度

.close-x {

    // ...



    &::before {

        transform: rotate(-45deg);

    }



    &::after {

        transform: rotate(45deg);

    }

}

渲染出来大概是这样的, 基本上就完成了

继续优化, 锦上添花

• 先来定义一个动画, 动画的意思是这样的:
  
  
  
  • 当为 0% 时旋转角为 0 度,
  
  
  • 当为 100% 时旋转角为 360 度
  
  
  
  

@keyframes rotating {

    0% {

        transform: rotate(0deg);

    }



    100% {

        transform: rotate(360deg);

    }

}

持续旋转

.rotate-infinite {

    animation: rotating .3s infinite linear;

}



// 使用方式 增加类 rotate-infinite

// 

加载时旋转一次

.rotate-one {

    animation: rotating .3s linear;

}



// 使用方式 增加类 rotate-one

// 

hover 时旋转一次

.rotate-hover:hover {

    .rotate-one();

}



// 使用方式 增加类 rotate-hover

// 

选中时旋转

.rotate-active:active {

    .rotate-infinite();

}



// 使用方式 增加类 rotate-active

// 

纯JS实现

function addCloseX(content) {

    const closeXSize = 20;

    const closeXLine = 2;



    const closeXWrap = document.createElement('div');

    closeXWrap.style.cssText = `

        position: relative;

        display: inline-block;

        width: ${closeXSize}px;

        height: ${closeXSize}px;

        cursor: pointer;

    `;



    const baseStyle = `

        display: block;

        height: 100%;

        width: ${closeXLine}px;

        margin: auto;

        background: #000;

    `;

    const xLineOne = document.createElement('i');

    xLineOne.style.cssText = baseStyle + `

        transform: rotate(45deg);

    `;

    const xLineTwo = document.createElement('i');

    xLineTwo.style.cssText = baseStyle + `

        margin-top: -100%;

        transform: rotate(-45deg);

    `;

    closeXWrap.appendChild(xLineOne);

    closeXWrap.appendChild(xLineTwo);



    content.appendChild(closeXWrap);

}



addCloseX(document.getElementById('close'))

需要提供一下注入的位置, 以上示例需要我们提供这样的 dmo 节点:

<div id="close">div>

• 这种方式没有使用样式表, 所有的样式都使用了行内样式的方式实现的


• 因为只用到了行内样式, 所以没办法使用伪元素, 故引入了两个 i 标签代替

结束

相关文档

CSS 实现圆(环)形进度条

不知道你有没有发现Bing AI聊天有个输入提示功能，在用户输入部分内容时后面会给出灰色提示文案。用户只要按下tab键就可以快速添加提示的后续内容。我将这个功能称为幽灵建议。接下来我将用Vue框架来实现这个功能。

布局样式

布局使用label标签作为容器，这样即使建议内容在上层，也不会影响输入框的输入。

<label class="container">

  <textarea></textarea>

  <div class="ghost-content"></div>

</label>

样式需要确保输入框与建议内容容器除了颜色外都要一致。建议内容可以通过z-index: -1置于输入框底部，但要注意输入框必须是透明背景。

.container {

  position: relative;

  display: block;

  width: 300px;

  height: 200px;

  font-size: 14px;

  line-height: 21px;

}

.container textarea {

  width: 100%;

  height: 100%;

  padding: 0;

  border: 0;

  font: inherit;

  color: #212121;

  background-color: #fff;

  outline: none;

}

.ghost-content {

  position: absolute;

  left: 0;

  right: 0;

  top: 0;

  bottom: 0;

  color: #212121;

  opacity: 0.3;

}

显示逻辑

显示逻辑比较简单，当输入框中显示输入内容时，找到匹配的内容后将其显示在建议容器中。以下是代码示例：

import { ref } from 'vue'



const content = ref('') // 输入框内容

const ghostContent = ref('') // 建议内容

const suggestions = ['你好啊', '怎么学编程'] // 建议列表



const handleInput = () => {

  ghostContent.value = '' // 内容变化时，清空建议

  // 如果为空或者建议内容改变，则不进行后续匹配

  if (content.value === '') {

    return

  }

  const suggestion = suggestions.find((item) => item.startsWith(content.value))

  if (suggestion) {

    ghostContent.value = suggestion

  }

}



const handleTabKeydown = () => {

  // 监听tab键按下，将输入框内容设置为建议内容，同时清空建议内容

  content.value = ghostContent.value

  ghostContent.value = ''

}

按照以上代码的写法，已经可以实现幽灵建议的功能了。但还存在一个小问题，输入框内容和建议内容的重叠部分会显得比较粗。因此，最好将重叠部分的文字颜色设置为透明。我的解决方法是使用span标签来包裹重叠部分的内容，然后将span的文字样式设置为透明。此外，为了表示可以使用tab键，我在末尾添加了→符号。改进后的代码如下：

// 重复部分省略

// ...

const ghostHTML = ref('') // 建议内容HTML

const handleInput = () => {

  ghostContent.value = ''

  ghostHTML.value = ''

  if (content.value === '' || fromSuggestion) {

    fromSuggestion && (fromSuggestion = false)

    return

  }

  const suggestion = suggestions.find((item) => item.startsWith(content.value))

  if (suggestion) {

    ghostContent.value = suggestion

    ghostHTML.value = suggestion.replace(content.value, `<span>${content.value}</span>`) + ' →' // 显示内容替换

  }

}



const handleTabKeydown = () => {

  content.value = ghostContent.value

  ghostContent.value = ''

  ghostHTML.value = ''

}

最后，补充一下HTML代码。

<label class="container">

  <textarea v-model="content" @input="handleInput" @keydown.tab.prevent="handleTabKeydown"></textarea>

  <div class="ghost-content" v-html="ghostHTML"></div>

</label>

• 我们需要阻止tab按下的默认事件，按下tab键会导致切换到其他元素，使输入框失去焦点；


• 使用v-html来绑定HTML内容。

因为工作的原因，我和一些外国前端开发有些交流。他们对于国内环境不了解，有时候会问出一些有趣的问题，大概是这些问题的启发，让我反复在思考一些更为深入的问题。

今天聊三个事情：

• 小程序
• 微前端
• 模块加载

小程序

每个行业都有一把银座，当坐上那把银座时，做什么便都是对的。

“我们为什么需要小程序？”

第一次被问到这个问题，是因为一个法国的同事。他被派去做一个移动端业务，刚好那个业务是采用小程序在做。于是一个法国小哥就在被痛苦的中文文档和黑盒逻辑中来回折磨着 🤦。

于是，当我们在有一次交流中，他问出了我这个问题：我们为什么需要小程序？

说实话，我试图解释了 19 年国内的现状，以及微信小程序推出时候所带来的便利和体验等等。总之，在我看来并不够深刻的见解。

即便到现在为止，每次当我使用小程序的时候，依旧会复现这个问题。在 ChatGPT 11 月份出来的时候，我也问了它这个很有国内特色的问题：

看起来它回答的还算不错，至少我想如果它来糊弄那些老外，应该会比我做的更好些。

但如果扪心自问，单从技术上来讲。以上这些事情，一定是有其他方案能解决的。

所以从某种程度上来看，这更像是一场截胡的商业案例：

应用市场

全世界的互联网人都知道应用市场是非常有价值的事情，可以说操作系统最值钱的部分就在于他们构建了自己的应用市场。

只要应用在这里注册发行，雁过拔毛，这家公司就是互联网世界里的统治阶级，规则的制定者。

反之则需要受制于人，APP 做的再大，也只是应用市场里的一个应用，做的好与坏还得让应用商店的评判。

另外，不得不承认的是，一个庞大如苹果谷歌这样的公司，他们的应用商店对于普通国内开发者来说，确实是有门槛的。

在国内海量的 APP 需求来临之前，能否提供一个更低成本的解决方案，来消化这些公司的投资？

毕竟不是所有的小企业都需要 APP，其实他们大部分需求 Web 就可以解决，但是 Web 没牌面啊，做 Web 还得砸搜索的钱才有流量。(某度搜索又做成那样...)

那做操作系统？太不容易，那么多人都溺死在水里了，这水太深。

那有没有一种办法可以既能构建生态，又有 APP 的心智，还能给入驻企业提供流量？

于是，在 19 年夏天，滨海大厦下的软件展业基地里，每天都在轮番播放着，做 XX小程序，拥抱下一个风口...

全新体验心智

小程序用起来挺方便的。

你有没有想过，这些美妙感觉的具体都来自哪些？以及这些真的是 Web 技术本身无法提供的吗？

1. 靠谱感，每个小程序都有约束和规范，于是你可以将他们整整齐齐的陈放在你的列表里，仿佛你已经拥有了这一个个精心雕琢的作品，相对于一条条记不住的网页地址和鱼龙混杂的网页内容来说，这让你觉得小程序更加的有分量和靠谱。
2. 安全感，沉浸式的头部，没有一闪而过的加载条，这一切无打扰的设计，都让你觉得这是一个在你本地的 APP，而不是随时可能丢失网页。你不会因为网速白屏而感到焦虑，尽管网络差的时候，你的 KFC 依旧下不了单 😂
3. 沉浸感，我不知道是否打开网页时顶部黑黑的状态栏是故意留下的，还是不小心的... 这些限制都让用户非常强烈的意识到这是一个网页而不是 APP，而小程序中虽然上面也存在一个空间的空白，但是却可以被更加沉浸的主题色和氛围图替代。网页这个需求做不了？我不信。

H5	小程序

4. 顺滑感，得益于 Native 的容器实现，小程序在所有的视图切换时，都可以表现出于原生应用一样的顺滑感。其实这个问题才是在很多 Hybrid 应用中，主要想借助客户端来处理和解决的问题。类似容器预开、容器切换等技术是可以解决相关问题的，只是还没有一个标准。

我这里没有提性能，说实话我不认为性能在小程序中是有优势的（Native 调用除外，如地图等，不是一个讨论范畴）。作为普通用户，我们感受到的只是离线加载下带来的顺滑而已。

而上述提到的许多优势，这对于一个高品质的 Web 应用来说是可以做得到的，但注意这里是高品质的 Web 应用。而这种“高品质”在小程序这里，只是入驻门槛而已。

心智，这个词，听起来很黑话，但却很恰当。当小程序通过长期这样的筛选，所沉淀出来一批这样品质的应用时。就会让每个用户即便在还没打开一个新的小程序之前，也有不错体验的心理预期。这就是心智，一种感觉跟 Web 不一样，跟 APP 有点像的心智。

打造心智，这件事情好像就是国内互联网企业最擅长做的事情，总是能从一些细微的差别中开辟一条独立的领域，然后不断强化灌输本来就不大的差异，等流量起来再去捞钱变现。

我总是感觉现在的互利网充斥着如何赚钱的想法，好像永远赚不够。“赚钱”这个事情，在这些公司眼里就是圈人圈地抢资源，看看谁先占得先机，别人有的我也得有，这好像是最重要的事情。

很少有企业在思考如何创造些没有的市场，创造些真正对技术发展有贡献，对社会发展有推动作用的事情。所以在国内互联网圈也充斥着一种奇怪的价值观，有技术的不一定比赚过钱的受待见。

管你是 PHP 还是 GO，管你是在做游戏还是直播带货，只要赚到钱就是高人。并且端的是理所应当、理直气壮，有些老板甚至把拍摄满屋子的程序员为自己打工作为一种乐趣。什么情怀、什么优雅、什么愿景，人生就俩字：搞钱。

不是故意高雅，赚钱这件事情本身不寒碜，只是在已经赚到盆满钵满、一家独大的时候还在只是想着赚更多的钱，好像赚钱的目的就是为了赚钱一样，这就有点不合适。企业到一定程度是要有社会责任的，龙头企业每一个决定和举措，都有会影响接下来的几年里这个行业的价值观走向。

当然也不是完全没有好格局的企业，我非常珍惜每一个值得尊重的中国企业，来自一个蔚来车主。

小程序在商业上固然是成功的，但吃的红利可以说还是来自 网页 到 应用 的心智变革。将本来流向 APP 的红利，截在了小程序生态里。

但对于技术生态的发展却是带来了无数条新的岔路，小程序的玩法就决定了它必须生长在某个巨型应用里面，不论是用户数据获取、还是 API 的调用，其实都是取决于应用容器的标准规范。

不同公司和应用之间则必然会产生差异，并且这种差异是墒增式的差异，只会随着时间的推移越变越大。如果每个企业都只关注到自己业务的增长，无外部约束的话，企业必然会根据自己的业务发展和政策需要，选择成本较低的调整 API，甚至会故意制造一些壁垒来增加这种差异。

小程序，应该是 浏览器 与 操作系统 的融合，这本应该是推动这两项技术操刀解决的事情。

微前端

qiankun、wujie、single-spa 是近两年火遍前端的技术方案，同样一个问题：我们为什么需要微前端？

我不确定是否每个在使用这项技术的前端都想清楚了这个问题，但至少在我面试过的候选人中，我很少遇到对自己项目中已经在使用的微前端，有很深的思考和理解的人。

先说下我的看法：

没有万能银弹

银色子弹（英文：Silver Bullet），或者称“银弹”“银质子弹”，指由纯银质或镀银的子弹。在欧洲民间传说及19世纪以来哥特小说风潮的影响下，银色子弹往往被描绘成具有驱魔功效的武器，是针对狼人、吸血鬼等超自然怪物的特效武器。后来也被比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。

所有技术的发展都是建立在前一项技术的基础之上，但技术依赖的选择过程中一定需要保留第一性原理的意识。

当 React、Vue 兴起，当 打包技术(Webpack) 兴起，当 网页应用(SPA) 兴起，这些杰出的技术突破都在不同场景和领域中给行业提供了新的思路、新的方案。

不知从何时开始，前端除了 div 竟说不出其他的标签(还有说 View 的)，项目中再也不会考虑给一个通用的 class 解决通用样式问题。

不知从何时开始，有没有权限需要等到 API 请求过后才知道，没有权限的话再把页面跳转过去申请。

不知从何时开始，大家的页面都放在了一个项目里，两个这样的巨石应用融合竟然变成了一件困难的事。

上面这些不合理的现状，都是在不同的场景下，不思考适不适合，单一信奉 “一招吃遍天” 下演化出的问题。

B 端应用，是否应该使用 SPA？ 这其实是一个需要思考的问题。

微前端从某种程度上来讲，是认准 SPA 了必须是互联网下一代应用标准的产物，好像有了 SPA 以后，MPA 就变得一文不值。甭管页面是移动端的还是PC的；甭管页面是面对 C 端的还是 B 端的；甭管一个系统是有 20 个页面还是 200 个页面，一律行这套逻辑。

SPA 不是万能银弹，React 不是万能银弹，Tailwind 不是万能银弹。在新技术出现的时候，保持热情也要保持克制。

ps. 我也十分痛恨 React 带来的这种垄断式的生态，一个 React 组件将 HTML 和 Style 都吃进去，让你即使在做一个移动端的纯展示页面时，也需要背上这些称重的负担。

质疑 “墨守成规”，打开视野，深度把玩，理性消费。

分而治之

分治法，一个很基本的工程思维。

在我看来在一个正常商业迭代项目中的主要维护者，最好不要超过 3 个人，注意是主要维护者(Maintainer) 。

你应该让每个项目都有清晰的责任人，而不是某行代码，某个模块。责任人的理解是有归属感，有边界感的那种，不是口头意义上的责任人。(一些公司喜欢搞这种虚头巴脑的事情，什么连坐…)

我想大部分想引入微前端的需求都是类似 如何更好的划分项目边界，同时保留更好的团队协同。

比如 导航菜单 应该是独立收口独立管理的，并且当其更新时，应该同时应用于所有页面中。类似的还有 环境变量、时区、主题、监控及埋点。微前端将这些归纳在主应用中。

而具体的页面内容，则由对应的业务进行开发子应用，最后想办法将路由关系注册进主应用即可。

当然这样纯前端的应用切换，还会出现不同应用之间的全局变量差异、样式污染等问题，需要提供完善的沙箱容器、隔离环境、应用之间通信等一系列问题，这里不展开。

当微前端做到这一部分的时候，我不禁在想，这好像是在用 JavaScript 实现一个浏览器的运行容器。这种本应该浏览器本身该做的事情，难道 JS 可以做的更好？

只是做到更好的项目拆分，组织协同的话，引入后端服务，由后端管控路由表和页面规则，将页面直接做成 MPA，这个方案或许并不比引入微前端成本高多少。

体验差异

从 SPA 再回 MPA，说了半天不又回去了么。

所以不防想想：在 B端 业务中使用 SPA 的优势在哪里？

流畅的用户体验：

这个话题其实涵盖范围很广，对于 SPA 能带来的 “流畅体验”，对于大多数情况下是指：导航菜单不变，内容变化 发生变化，页面切换中间不出现白屏。

但要做到这个点，其实对于 MPA 其实并没有那么困难，你只需要保证你的 FCP 在 500ms 以内就行。

以上的页面切换全部都是 MPA 的多页面切换，我们只是简单做了导航菜单的 拆分 和 SWR，并没有什么特殊的 preload、prefetch 处理，就得到了这样的效果。

因为浏览器本身在页面切换时会在 unload 之前先 hold 当前页面的视图不变，发起一下一个 document 的请求，当页面的视图渲染做到足够快和界面结构稳定就可以得到这样的效果。

这项浏览器的优化手段我找了很久，想找一篇关于它的博文介绍，但确实没找到相关内容，所以 500ms 也是我的一个大致测算，如果你知道相关的内容，可以在评论区补充，不胜感激。

所以从这个角度来看，浏览器本身就在尽最大的努力做这些优化，并且他们的优化会更底层、更有效的。

离线访问 (PWA)

SPA 确实会有更好的 PWA 组织能力，一个完整的 SPA 应用甚至可以只针对编译层做改动就可以支持 PWA 能力。

但如果看微前端下的 SPA 应用，需要支持 PWA 那就同样需要分析各子应用之间的元数据，定制 Service Worker。这种组织关系和定制 SW，对于元数据对于数据是来自前端还是后端，并不在意。

也就是说微前端模式下的 PWA，同样的投入成本，把页面都管理在后端服务中的 MPA 应用也是可以做到相同效果的。

项目协同、代码复用

有人说 SPA 项目下，项目中的组件、代码片段是可以相互之间复用的，在 MPA 下就相对麻烦。

这其实涉及到项目划分的领域，还是要看具体的需求也业务复杂度来定。如果说整个系统就是二三十个页面，这做成 SPA 使用前端接管路由高效简单，无可厚非。

但如果你本身在面对的是一个服务于复杂业务的 B 端系统，比如类似 阿里云、教务系统、ERP 系统或者一些大型内部系统，这种往往需要多团队合作开发。这种时候就需要跟完善的项目划分、组织协同和系统整合的方案。

这个时候 SPA 所体现出的优势在这样的诉求下就会相对较弱，在同等投入的情况下 MPA 的方案反而会有更少的执行成本。

也不是所有项目一开始就会想的那么清楚，或许一开始的时候就是个简单的 SPA 项目，但是随着项目的不断迭代，才变成了一个个复杂的巨石应用，现在如果再拆出来也会有许多迁移成本。引入微前端，则可以...

这大概是许多微前端项目启动的背景介绍，我想说的是：对于屎山，我从来不信奉“四两拨千斤”。

如果没有想好当下的核心问题，就引入新的“银弹”解决问题，只会是屎山雕花。

项目协同，抽象和复用这些本身不是微前端该解决的问题，这是综合因素影响下的历史背景问题。也是需要一个个资深工程师来把控和解决的核心问题，就是需要面对不同的场景给出不同的治理方案。

这个道理跟防沙治沙一样，哪有那么多一蹴而就、立竿见影的好事。

模块加载

模块加载这件事情，从玉伯大佬的成名作 sea.js 开始就是一个非常值得探讨的问题。在当时 jQuery 的时代里，这是一个绝对超前的项目，我也在实际业务中体会过在无编译的环境下 sea.js 的便捷。

实际上，不论是微前端、低代码、会场搭建等热门话题离不开这项技术基础。

import * from * 我们每天都在用，但最终的产物往往是一个自运行的 JS Bundle，这来自于 Webpack、Vite 等编译技术的发展。让我们可以更好的组织项目结构，以构建更复杂的前端应用。

模块的概念用久了，就会自然而然的在遇到浏览器环境中，遇到动态模块加载的需求时，想到这种类似模块加载的能力。

比如在遇到会场千奇百怪的个性化营销需求时，能否将模块的 Props 开放出来，给到非技术人员，以更加灵活的方式让他们去做自由组合。

比如在低代码平台中，让开发者自定义扩展组件，动态的将开发好的组件注册进低代码平台中，以支持更加个性的需求。

在万物皆组件的思想影响下，把一整个完整页面都看做一个组件也不是不可以。于是在一些团队中，甚至提倡所有页面都可以搭建、搭建不了的就做一个大的页面组件。这样及可以减少维护运行时的成本，又可以统一管控和优化，岂不美哉。

当这样大一统的“天才方案”逐渐发展成为标准后，也一定会出现一些特殊场景无法使用，但没关系，这些天才设计者肯定会提供一种更加天才的扩展方案出来。比如插件，比如扩展，比如 IF ELSE。再后来，就会有性能优化了，而优化的 追赶对象 就是用原来那种简单直出的方案。

有没有发现，这好像是在轮回式的做着自己出的数学题，一道接一道，仿佛将 1 + 1的结论重新演化了一遍。

题外话，我曾经自己实现过一套通过 JSON Schema 描述 React 结构的 “库” ，用于一个低代码核心层的渲染。在我的实现过程中，我越发觉得我在做一件把 JSX 翻译成 JS 的事情，但 JSX 或者 HTML 本身不就是一种 DSL 么。为什么一定要把它翻译成 JSON 来传输呢？或者说这样的封装其本身有意义么？这不就是在做 PHP、.Net 直接返回带有数据的 HTML Ajax 一样的事情么。

传统的浏览器运行环境下要实现一个模块加载器，无非是在全局挂载一个注册器，通过 Script 插入一段新的 JS，该 JS 通过特殊的头尾协议，将运行时的代码声明成一个函数，注册进事先挂载好的注册器。

但实际的实现场景往往要比这复杂的多，也有一些问题是这种非原生方式无法攻克的问题。比如全局注册器的命名冲突；同模块不同版本的加载冲突；并发加载下的时序问题；多次模块加载的缓存问题 等等等等等...

到最后发现，这些事情好像又是在用 JS 做浏览器该做的事情。然而浏览器果然就做了，，Vite 就主要采用这种模式实现了它 1 年之内让各大知名项目切换到 Vite 的壮举。

“但我们用不了，有兼容性问题。”

哇哦，当我看着大家随意写出的 display: grid 样式定义，不禁再次感叹人们对未知的恐惧。

import.meta 的兼容性是另外一个版本，是需要 iOS12 以上，详情参考：caniuse.com/?search=imp…

试想一下，现在的低代码、会场搭建等等各类场景的模块加载部分，如果都直接采用 ESM 的形式处理，这对于整个前端生态和开发体验来说会有多么大的提升。

模块加载，时至今日，本来就已经不再需要 loader。 正如 seajs 中写的：前端模块化开发那点历史

历史不是过去，历史正在上演。随着 W3C 等规范、以及浏览器的飞速发展，前端的模块化开发会逐步成为基础设施。一切终究都会成为历史，未来会更好。

结语

文章的结尾，我想感叹另外一件事，国人为什么一定要有自己的操作系统？为什么一定需要参与到一些规范的制定中？

因为我们的智慧需要有开花的土壤，国内这千千万开发者的抱负需要有地方释放。

如果没有自己掌握核心技术，就是只能在问题出现的时候用另类的方式来解决。最后在一番折腾后，发现更底层的技术只要稍稍一改就可以实现的更好。这就像三体中提到的 “智子” 一样，不断在影响着我们前进的动力和方向。

不论是小程序、微前端还是模块加载。试想一下，如果我们有自己的互联网底蕴，能决定或者影响操作系统和浏览器的底层能力。这些 “怪啖” 要么不会出现，要么就是人类的科技创新。

希望未来技术人不用再追逐 Write Once, Run Everywhere 的事情...

原文链接： typefully.com/DanHollick/…

作者：Dan Hollick

你有想过QR码是如何工作的吗？

我也没有想过，但是它真的很低调很迷人～

【警告】这里有一些非常书呆子的东西👇 )

QR码是由丰田的一个子公司发明的，目的是为了在整个制造过程中跟踪零件信息。

之前出现的条形码被证明是不足够的 - 它们只能从特定的角度读取，并且相对于他们的大小来说，并不能储存很多的数据。

那么 QR 码不只解决了这些问题

QR 码最独一无二的地方在于这些正方体，这些正方体被称为“查找器”，这些正方体帮助了你的阅读器检测到码的存在。

第四个小的正方体，被称作对齐模式，它是用来定向代码的，使它可以在任何角度呈现，阅读器仍然哪个方向是向上的。

你可能从来都没有注意过，但是每个 QR 码都有这些叫做定时模式的黑白相间的点。

这些黑白相间的点告诉阅读器单个模块有多大以及整个 QR 码有多大 -- 也就是版本。

版本一：最小的。
版本四十：最大的。

关于格式的信息被存在查找器旁边的两个条纹中。

它被存储了两次，所以即使QR码被部分遮挡，它也是可读的。(你会注意到这是一个反复出现的主题。)

它存储了三个重要的信息片段

我知道这听起来很无聊，但是实际上，他还是很有意思的（doge

首先，纠错 - 这是什么玩意？

从本质上讲，它规定了在 QR 码中存储多少冗余信息，以确保即使部分信息丢失也能保持可读。

这真的很酷好吗 - 如果您的代码在户外，您可以选择更高的冗余级别，以确保它在模糊的时候也能正常工作。

试试下面这个二维码

第二个，这个 mask，这个是个什么东西？

首先你需要知道，QR 阅读器在黑色区域和白色区域的数量一样的时候工作的最好。

但是数据可能无法发挥作用，因此使用掩码来平衡。

当掩版应用于QR码时，任何落在掩码暗部的东西都会被反转。

白色区域变成黑色，黑色区域变成白色。

有8种标准模式，一个接一个地应用。使用达到最佳结果的模式，并存储该信息，以便读者可以不应用掩码。

最后呢，就到了我们的实际数据的部分。

奇怪的是，数据从右下角开始，然后像图中那样蜿蜒而上。

从哪开始几乎不重要了，因为它可以从每个角度读取。

这里的第一个信息块告诉读者数据是以什么模式编码的，第二个告诉它长度。

在我们的例子中，每个字符占用8位块，或者称为字节，共有24个字节。

在我们的数据之后还有一些剩余的空间。这是存储纠错信息的地方，以便在部分模糊的情况下可以读取。它的工作方式实际上非常非常复杂，所以我把它省略了。基本上就是这样!

对于制作 QR 码的书呆子来说，一个有意思的事实是: QR码最酷的事情是发明QR码的Denso Wave公司从未行使他们的专利，并且免费发布这项技术!

背景

• 设计：我想要的你听明白了吗，你做出来的和我想要的差距很大，你怎么没有一点审美（你个臭男人，你怎么不按我画的做）！


• 我：啊？这样自适应不是很好吗，适配了大部分机型呀，而且不会有啥显示的兼容性，避免不必要的客户咨询和客户投诉。


• 设计： 你上一家公司就是因为有你这样的优秀员工才倒闭的吧？！


• 我：啊？ntm和产品是一家的是吗？

我该如何应对

先看我实现的

在看看设计想要的

总结一下：

• 1.一个的时候宽度固定，不管屏幕多大都占屏幕的一半。


• 2.俩个的时候，各占屏幕的一半，当屏幕过小的时候两个并排展示换行。


• 3.三个的时候，上面俩，下面一个，且宽度要一样。


• 4.大于三个的时候，以此类推。

有句话叫做什么，乍一看很合理，细想一下，这不是扯淡么。

所以我又和设计进行了亲切的对话

• 我：两个的时候你能考虑到小屏的问题，那一个和三个的时候你为啥不考虑，难道你脑袋有泡，在想一个和三个的时候泡刚好堵住了？


• 设计： 你天天屌不拉几的，我就要这样，这样好看，你懂个毛的设计，你知道什么是美感和人体工学设计，视觉效果拉满吗？


• 我：啊？我的姑奶奶耶，你是不是和产品一个学校毕业的，咋就一根筋呢？


• 产品：ui说的对，我听ui的。汪汪汪（🐶）

当时那个画面就像是，就像是：

而我就像是

那咋办，写呗，我能咋办？

我月黑风夜，
黑衣傍我身，
潜入尔等房，
打你小屁屁？

代码实现

   class={[

      'group-even-number' : this.evenNumber,

      'group-odd-number' : this.oddNumber,

      'themeSelectBtnBg'

      ]}

      value={this.currentValue}

      onInput={(value: any) => {

        this.click(value)

      }}

    >

      ...

    

   .themeSelectBtnBg {

       display: flex;

       &:nth-child(2n - 1) {

         margin-left: 0;

         margin-right: 10px;

       }

       &:nth-child(2n) {

         margin-left: 0;

         margin-right: 0;

       }

       

   }

   // 奇数的情况，宽度动态计算，将元素挤下去

   .group-odd-number {

    // 需要减去padding的宽度

    width: calc(50% - 7.5px);

   }

   

   .group-even-number {

     justify-content: space-between;

     @media screen and (max-width:360px) {

        justify-content: unset;

        margin-right: unset;

        flex: 1;

        flex-wrap: wrap;

      }

   }

行吧，咱就这样吧

时间过得真快，从20年9月加入美团，转眼已经三年了。在美团的这几年，我应该有接近一半的时间，在做前端工程化相关的工作。

三年，正好合同已经到期，也到了离开的时候，最近相对不忙，正好回顾一下自己做前端工程化的一些思考与踩过的坑。

对前端工程的理解

前端技术的演进

在谈前端工程这个概念之前，我们先回顾一下2000年以后前端技术的演进，主要分四个阶段：

• 页面开发阶段（2000~2009） ：在ECMAScript 2009发布之前，很多前端工作都是以单页面开发为主，需要重点解决兼容性问题，靠工具库提高效率，代表技术如：jQuery、ExtJS等。


• 模块化开发阶段（2009~2015） ：以模块化开发为主，要解决性能问题，靠构建工具和UI框架提高效率，特别是基于Node.js的各种前端工具，代表技术如：Angular、React、Less、Gulp等。


• 应用开发阶段（2015~2022） ：以应用开发为主，要解决工程化问题，靠自动化工具和跨平台提高效率，代表技术如：Webpack、React Native、Flutter等。


• 智能辅助开发阶段（2022以后） ：将前端工程化与 AI 结合，将重复冗余的流程通过智能化实现开发提效，实现智能代码生成、评审、智能编写单测、代码语言转化等。

软件工程的三要素

同时，我们也需要了解一下软件工程的概念。1983年IEEE是这么定义的：软件工程是软件开发、运行、维护和修复软件的系统方法。

基于此，软件界一些前辈提出了软件工程的三要素：

• 方法：是完成软件开发的各项任务的技术方法，为软件开发提供“如何做”的技术。


• 工具：为运用方法而提供的自动的或半自动的软件工程的支撑环境。


• 过程：是为了获得高质量的软件所需要完成的一系列任务的框架。

前端工程化的定义

前端工程化这个词，是国内前端圈子2018年前后才出现的，大概的意思是将（后端已经比较成熟的）许多软件工程概念、实践、工具引入前端开发，提升开发效率。

关于前端工程化的定义，众说纷纭。我们团队在21年初，经过三个多月的调研和讨论，才形成了一个大家都能认可的定义：在前端开发和运维过程中，以降低成本、提高效率、保障质量为目的，通过一系列规范、工具、流程（分别对应软件工程中的方法、工具和过程）作为手段的实践体系。

前端工程化的演进

美团由于业务广泛，大大小小的前端团队得有30个以上，每个团队的业务场景不同，都会建设或采用一套合适的前端工程方案，但其演进过程，一般都会经历以下阶段：

• 工具化：以针对各自业务场景开发脚手架为主，内置常用的前端组件库，提供代码格式检查、埋点及监控等插件，提升项目初始化的效率。


• 规范化：面向完成需求的整个研发流程，梳理需求管理、视觉交互设计、评审、开发、联调、测试验收、上线部署和质量监控等相关的规范，进一步建设工具来约束研发过程中的不确定性。


• 平台化：将支撑研发的有关工具和系统聚合起来，通过套件和插件的设计模式，实现对不同场景的支撑，支持在线初始化项目，横向打通研发的整体链路。


• 体系化：紧跟前沿技术，集成低代码、在线IDE、代码智能生成或推荐等能力，建设需求、设计、研发、运营一体化的云开发平台。

中后台项目的工程化实践

工程化演进的动力，源于业务复杂度的增加及团队规模的扩大。我在美团工作过的两个部门，都是属于基础研发平台的，在我加入后，所在前端团队需要开发维护的中后台项目都在变多(第一个部门有60多个，第二个部门也有10多个)，团队规模也进一步扩大(第一个部门30多人，第二个部门10多人)。

在第二个部门的工程化，主要借助我在第一个部门的前端工具建设，进行定制化应用。因此，着重介绍一下我在第一个部门的前端工程化实践。

工具建设

团队的工具建设，开始于2018年，为了建设美团私有云平台，需要收拢美团基础研发平台所有 IaaS、PaaS 产品，预期两年内会有几十个增量项目接入，我们需要提供高效、稳定的前端支持。急需解决的问题有：

• 缺乏研发工具。 这一时期，我们的开发手段还比较原始，业务强相关的大量重复工作难以避免，如：前端工程的搭建，接入统一通用的SDK。


• 机器资源不足。 当时的前端项目还是直接部署在机器上，团队能申请的机器资源有限，难以承接即将接入的大量项目。

针对这两个问题，首先我们建设了自己脚手架工具，并统一了研发流程：

• 项目模板：我们提供了两套模板用于初始化项目，一套适用于接入私有云平台(面向美团所有研发，需要统一的顶导、侧导，对视觉交互要求高，上线管控严格)，一套适用于普通的后台管理(只是部门内少数研发使用，重在快速实现功能)。


• 研发工具：通过一套自研的中后台组件库把控整体的视觉交互，并提供私有云平台本地开发调试的代理转发工具，解决接口请求的鉴权问题。


• 集成服务工具：提供了将本地静态资源发布到云存储和接入公司埋点监控等服务的工具，简化和统一了不同项目接入相同的服务。

其次，我们升级了静态资源部署方案：团队的前端大多数项目都是纯静态页面，可以使用云存储代替机器存储，从而解放大多数机器资源。故而我们基于 s3plus 对象存储，研发配套的部署工具，实现了静态 web 项目的无服务架构。

规范制定

到 2020 年的时候，我们需要支持 80 多个基础技术中后台项目的前端工作，当时团队支持项目上存在以下 2 个问题：

• 无规范，协作难。 随着团队规模的扩大，各个小组的规范和工具出现分叉，同类项目有多套规范及协作工具，跨项目及跨职能协作同学认知和上手成本高，跨项目协作或人员调动阻力大。


• 工具分散，存在内耗。 团队共存多套同类工具，低水平轮子多，维护成本高；工具没有形成生态，不能发挥规模效应，效率提升有限。

首先，我们联合多个小组接口人，共同梳理标准规范，并通过标准宣讲，拉齐各职能角色的认知，最终形成了六个大类(分别为需求、设计、研发、发布、架构和运维)、26个小类的文字版规范。

然后，我们联合多个部门的前端物料接口人，基于中后台项目前端界面的常见场景，制定了统一的设计规范，从零建设区块和页面模板库，整合已有的基础组件、业务组件和项目模板，形成了完整的前端物料体系。

接着，我们把发布工具从 Plus 平台迁移至 DevTools 流水线，并且通过 WebStatic 平台进行静态网站托管。这样的好处是，发布规则可以通过流水线定制，加入标准化监测度量等工具，从而实现卡控；流水线运行的容器天然可以作为中转站，将前端资源发布S3，解放了机器；WebStatic 平台接管静态网站托管，可以让我们省去复杂重复的路由配置。

最后，我们采用“普法”和“执法”并重的原则，首先通过课程分享和改造宣讲，普及并对齐标准化的价值，完成团队“普法”过程。“执法”前，我们基于标准沉淀多种一键接入工具降低接入成本；无法自动接入的标准，官方给出最佳实践及预计改造时长，协助业务同学排期；“执法”中，提供了检查工具，用于标准校验并收集项目标准化数据，帮助标准化持续运营。

同时，我们把规范标准区分“强制”、“推荐”两个等级。存量项目只需遵守“强制”等级，不影响项目进度的前提下达成团队标准下限；对于增量项目，提供工具高效遵循全部标准。

搭建平台

2021年团队引入了大量前端外包同学，原本的研发工具及增量项目的服务搭建对于外包同学，都有较高的学习成本，因此这一年我们将提效的重点放在了研发工具的体验优化，以及发布规范、架构规范的配套工具落地。主要解决如下问题：

• 架构规范难学习。项目从创建到上线，需要对接代码仓库、Appkey、发布工具、资源托管服务及网关配置等，涉及基础服务产品多，申请及系统切换操作复杂，即使工作经验丰富，也未必熟悉项目所需的全部中间件。


• 部分研发工具难上手，体验较差。研发套件中包含工具类型繁多，建设初期，文档完善程度参差不齐，高频使用的物料工具对于新人上手也不够友好。

我们决定通过建设研发工作台落地架构规范，通过自动化的研发流程串联降低新人学习成本，快速搭建增量项目；同时，为解决研发套件使用体验问题，我们同步建设了 VSCode IDE插件，集成高频使用的插件、物料使用等工具，降低学习和切换成本，增强用户的使用体验。

同时，为满足不同业务场景的定制需求，我们将各场景研发流程抽象成 「场景模板」， 它是最佳实践的载体，前文中的自动化创建流程就是基于场景模板来串联。

场景模板由初始化模板（生成项目基础结构），研发工具插件（CLI 层面的插件 preset），基础服务配置方案组成，每部分可以灵活配置，一定程度上满足不同业务场景的定制需求，团队工程负责人可以按需定制自己的场景模板。

平台化以后，我们的前端工程方案就可以满足公司更多部门接入使用，发挥更大的价值。比如，我转岗的部门在推进工程化的时间，基于这套方案，只需结合视觉项目的特点，替换前端物料、生成项目的脚手架即可。

形成体系

2022年外包团队规模和产品规模即将进一步扩大，然而当前工具对于效率的提升也逐渐出现瓶颈，我们期望对当前的主要业务场景，即对中后台业务，进行深度提效的探索。另一方面，现有大部分规范已有配套工具保障，但前置的需求以及后置的运维环节依然没有形成闭环，我们期望平台能有更沉浸式的体验，建设中后台场景的体系化解决方案。需要解决以下问题：

• 提效瓶颈，研发提效工具待加强： 分析业务现状和参考业界，传统编码（ProCode）的辅助工具完整性和易用性需持续加强，业界的低代码（LowCode）实践也很适用于我们的中后台场景，我们也将在这一领域探索建设。


• 需求、运维规范未闭环： 当前的平台能够串联从创建项目到部署的研发流程，但是前置的需求、设计管理和后置的运维规范还不完善，对于相关工具（如项目管理和监控工具）的应用也没有形成标准。

我们希望将研发工作台打造为云开发平台，通过集成在线 IDE 开发工具和低代码自动化研发工具，对于中后台场景深度提效；同时也要与项目管理、设计平台、监控等平台加深协作与融合，串联前置的需求设计环节与后置的运维环节，形成中后台场景的体系化开发平台。

sdk项目的工程化实践

2022年初，为了从北京换到深圳定居，我换了部门，在新的部门，需要开发维护的npm包比之前多了很多。如果没有统一的工程标准，不仅开发维护的效率很低，同时SDK的易用性也会比较差。

过去一年，我参与了多个SDK项目的开发维护工作，同时前两年也参与了面向公司的中后台前端项目的工程建设，于是我将这些实践和采坑经验进行总结，形成了一套前端sdk项目的工程标准。

业务项目和SDK项目的区别

通过表格对比可以看到，业务项目和SDK的项目还是有较大区别的，除了有一些公共标准可以复用外，SDK项目需要增加打包构建、发npm包、多包管理、文档管理和门户建设等相关的工程标准。

工程方案

我们基于业务项目制定的规范，对于有差异的部分，比如依赖包管理方案、目录结构、文件命名、本地开发等，制定了新的规范；而对于没有包含的部分，比如文档管理、官网建设、发布npm包及其权限管理等，补充了新的规范。

我们基于前面建设的云开发平台，提供了一个面向 SDK 开发的场景模板来创建项目：创建成功后，会自动注册前端appkey，创建仓库并使用sdk的项目模板初始化项目，把sdk官网的静态资源接入webstatic，并接入发布流水线，提供默认域名供用户访问。

相比之前的方案，这个方案不仅开发调试及发布验证更加方便，还能提供默认的域名访问该sdk网站，让用户可以快速查看相关的接入文档和教程，体验sdk提供的功能。

相关说明

整个项目使用vite工具进行构建，使用rollup 进行打包，打包成功后，即可通过本地或流水线发布到公司的私有npm。

我们没有使用lerna进行多包管理，而是使用了pnpm的方案，所以要求必须本地安装pnpm，然后通过pnpm安装package.json文件中引入的npm包。

只需配置根目录下的pnpm-workspace.yaml文件即可，示例如下：

packages:

  - 'packages/**'

  - site

在packages目录下，一个子目录对应为一个子npm包。site 目录为sdk 对应的官网代码，本地开发时，可以在site 中的某个页面，引入packages中的某个包进行源码调试。

在根目录执行 npm start 就可以打开sdk 官网了，然后跳转到demo 演示的页面，修改site目录下对应页面或者packages下对应的npm包，即可开始进行SDK的开发调试了。

所有的文档管理相关代码，都在site 目录下的src目录，如果需要更新文档，直接在markdown 目录编辑对应的文档即可。

如果发布了新的sdk，需要验证sdk的可用性，需要先将site目录下package.json文件对应的npm包修改为最新的版本，提交后远程仓库后，再选择对应流水线发布到自己想验证的环境。

总结

在美团工作的三年，在技术和视野上，对我的帮助都很大，接触的领导和身边的小伙伴都很优秀，有些工作是我对最终结果负责，有些我只是重在参与。

我们会把事情分为业务开发和框架（工具）开发：

• 业务开发主要是实现产品需求，要对业务有深入了解，掌握团队所用到的技术栈和工具。


• 框架（工具）开发主要是为提升业务开发效率而开发的框架或工具，框架是把系统可复用层抽象出来，如网络层，存储层等，工具是研发过程中效率工具，如自动化测试工具，持续交付工具等。

通常上系统是有多个模块组成，那么会有一个从复杂到简单的拆解过程，既然系统有分层架构，那我们会按照每个人技术水平来安排不同复杂度的工作。我们要不断提升两个标准，一是通过对人才的培养提高上限，二是通过工程工具建设提升团队下限。

工程化永远是围绕着质量、体验和效率三个维度进行建设，来保证高效、高质量地完成业务需求，减少跨项目、跨团队的协作成本。但前端工程化不是万金油，它是在特定时期面对特定场景的解决方案。

平台体系的建设往往会被业务结构和技术架构所约束，要尽量结合团队的业务场景和技术现状来制定合理的解决方案，避免仅凭个人的技术思考来主观驱动，所以还是要结合自身组织特点，先清楚地认识自己所处的阶段，再去实践并验证。

老王（王慧文）在演讲曾提到过：“不要为自己设限”，所以前端工程师在前端工程化中，应该积极承担业务工程化建设或工程工具建设工作。《论语》中说道：“工欲善其事，必先利其器”，所以面对复杂工程，我们要学会用工具来提升效率，使复杂问题简单化。

2023年我的主要精力都在做前端智能化，在工程化上的投入比较少，但是我相信借助AI，前端工程化一定会迎来重大的变革。

随着经济的下行以及移动互联网发展趋于成熟，对软件开发人员的需求大大减少，互联网行业所有的公司都在降本增效，合并通道，降薪裁员的新闻层出不穷。

但相比其他行业，互联网行业的从业者薪资还是比较可观的，但要求也比之前高了很多，需要大家掌握更多的技能和在某些技术领域深耕。

本文，我们就聊聊，掌握了哪些技能，能让前端同学，收入高且稳定。

端智能

首推的是端智能，很多行业大咖都认为，随着ChatGPT的横空出世，开启了第四次工业革命，很多产品都可以用大模型重做一遍。当前，我创业的方向，也和大模型有关。

当前的大模型主要还跑在云端，但云端的成本高，大模型的未来在端智能，这也是小米创始人雷军在今年一次发布会上提出的观点。

在2023年8月14日的雷军年度演讲中，雷军宣布小米已经在手机端跑通13亿参数的大模型，部分场景效果媲美云端。

目前，端上大模型的可行性和前景已经得到了业内的普遍认可，国内外各个科技大厂在大模型的端侧部署领域均开始布局，目前大量工程已在PC端、手机端实现大模型的离线部署，更有部分App登陆应用商店，只需下载即可畅通无阻地对话。

我们相信，在不久的将来，端上大模型推理将会成为智能应用的重要组成部分，为用户带来更加便捷、智能的体验。

我在美团从零研发了web端智能推理引擎，当时立项时，就给老板画饼，美团每天的几百亿推理调用，如果有一半用端智能替代的话，每年能为公司节省上亿元。

要想掌握端智能，需要学习深度学习的基本知识，还要掌握图形学和C++编程，通过webgl或webassembly 技术实现在Web端执行深度学习算法。

图形学

前面提到的端智能，只是涉及到了图形学中的webgl计算，但图形学的未来在元宇宙，通过3D渲染，实现VR、AR、XR等各种R。

计算机图形学是一门快速发展的领域，涵盖了三维建模、渲染、动画、虚拟现实等众多技术和应用。在电影、广告、游戏等领域中，计算机图形学的应用已经非常广泛。

熟练使用threejs开发各种3D应用，只能算是入门。真正的图形学高手，不仅可以架构类似3D家装软件的大型应用，而且能掌握渲染管线的底层原理，熟练掌握各种模型格式和解决各种软件，进行模型转换遇到的各种兼容问题。

随着计算机硬件和算法的不断进步，计算机图形学正迎来新的发展趋势。

首先是实时渲染与逼真度提升

• 实时渲染技术：随着游戏和虚拟现实的兴起，对实时渲染的需求越来越高。计算机图形学将继续致力于研发更高效的实时渲染算法和硬件加速技术，以实现更逼真、流畅的视觉效果。


• 光线追踪与全局照明：传统的实时渲染技术在光照模拟方面存在挑战。计算机图形学将借助光线追踪等技术，实现更精确的全局照明效果，提升场景的真实感和细节表现。

其次是虚拟与增强现实的融合

• 混合现实技术：计算机图形学将与传感器技术、机器视觉等相结合，推动虚拟现实与增强现实的融合发展。通过实时感知和交互，用户可以在真实世界中与虚拟对象进行互动，创造更沉浸式的体验。


• 空间感知与虚拟对象定位：计算机图形学将致力于解决空间感知和虚拟对象定位的挑战。利用深度学习、摄像头阵列等技术，实现高精度的空间感知和虚实融合，为虚拟与增强现实应用带来更自然、精确的交互方式。

再次是计算机图形学与人工智能的融合

• 生成对抗网络（GAN）在图形生成中的应用：GAN等人工智能技术为计算机图形学带来了新的创作手段。通过训练模型生成逼真的图像和场景，计算机图形学能够更便捷地创建大量内容，并提供个性化的用户体验。


• 计算机图形学驱动的虚拟人物与角色生成：结合计算机图形学和人工智能技术，研究人员正在努力开发高度逼真的虚拟人物和角色生成方法。这将应用于游戏、影视等领域，带来更具情感表达和交互性的虚拟角色。

最后是可视化分析与科学研究。

• 一是大数据可视化：随着大数据时代的到来，计算机图形学在可视化分析方面扮演着关键角色。通过创新的可视化方法和交互技术，研究人员能够更深入地理解和分析庞大而复杂的数据集，揭示潜在的模式和趋势。


• 二是科学数据可视化：计算机图形学在科学研究中的应用也日益重要。通过将科学数据转化为可视化形式，研究人员能够更直观地理解复杂的数据模式和关系，加快对科学问题的洞察和发现。这种可视化分析有助于领域如天文学、生物学、气象学等的研究进展。

工程提效

其实，过去三年我在美团的工作，至少有一半的精力是做和工程提效相关的事情。当然，也做了降本的事情，从零搭建外包团队。

就像我之前总结的文章：我在美团三年的前端工程化实践回顾 中提到那样，前端工程提效，一般会按照工具化、标准化、平台化和体系化进行演进。

相比前面的端智能和图形学，除了建设低代码平台和WebIDE有点技术难度，其他更多需要的是沟通、整合资源的能力，既要有很强的项目管理能力，又要人产品思维。

前两个方向做好了我们一般称为技术专家，而工程提效则更偏管理者，未来可以成为高管或自己创业。

总结

端智能和图形学，我在美团都尝试过进行深耕，但自己性格外向，很难坐得住。工程提效做得也一般，主要是因为需要换城市而换了部门，没有机缘继续推进，在美团很难往上走，所以只能尝试自己创业。

背景

记得几年前做了一个报告，报告里面加载的是用户的历年作品还有会员信息，然后按照年月倒序展示出来，其中历年作品都要将作品的封面展示出来。一开始这个报告到没啥问题，而且一个时间轴下来感觉挺好，有用户的作品、会员记录、关注以及粉丝记录很全面。直到最近忽然有一批用户说一进到这个报告页面就卡住不动了，上去一查发现不得了，都是铁杆用户，每年作品都几百个，导致几年下来，这个报告返回了几千个作品，包含上千的图片。

问题分析

上千的图片，肯定会卡，首先想到的是做图片懒加载。这个很简单，使用一个vue的全局指令就可以了。但是上线发现，没啥用，dom节点多的时候，懒加载也卡。

然后就问服务端能不能支持分页，服务端说数据太散，连表太多，树形结构很难做分页。光查询出来就已经很费劲了。

没办法于是想了一下如何前端来处理掉。

思路

实现

本文仅展示一种基于vue的实现

1. 容器

设计一个可以进行滚动翻页的容器 然后绑定滚动方法OnPageScrolling

<style lang="less" scoped>



.study-backup {



overflow-x: hidden;



overflow-y: auto;



-webkit-overflow-scrolling: touch;



width: 100%;



height: 100%;



position: relative;



min-height: 100vh;



background: #f5f8fb;



box-sizing: border-box;



}



</style>



<template>



<section class="report" @scroll="OnPageScrolling($event)">



</section>



</template>

2.初始化数据

这里定义一下树形列表的数据结构，实现初始化渲染，可以渲染一个树节点，或者一个树节点的部分子节点

GetTreeData() {



treeapi



.GetTreeData({ ... })



.then((result) => {



// 处理结果



const data = Handle(result)



// 这里备份一份数据 不参与展示



this.backTreeList = data.map((item) => {



return {



id: item.id,



children: item.children



}



})



// 这里可以初始化为第一个树节点



const nextTree = this.backTreeList[0]



const nextTansformTree = nextTree.children.splice(0)



this.treeList = [{



id: nextTree.id,



children: nextTansformTree



}]



// 这里可以初始化为第一树节点 但是只渲染第一个子节点



const nextTree = this.backTreeList[0]



const nextTansformTree = nextTree.children.splice(0, 1)



this.treeList = [{



id: nextTree.id,



children: nextTansformTree



}]



})



},

3.滚动加载

这里通过不断的把 backTreeList 的子节点转存入 treeList来实现分页加载。

OnPageScrolling(event) {



const container = event.target



const scrollTop = container.scrollTop



const scrollHeight = container.scrollHeight



const clientHeight = container.clientHeight



// console.log(scrollTop, clientHeight, scrollHeight)



// 判断是否接近底部



if (scrollTop + clientHeight >= scrollHeight - 10) {



// 执行滚动到底部的操作



const currentReport = this.backTreeList[this.treeList.length - 1]



// 检测匹配的当前树节点 treeList的长度作为游标定位



if (currentReport) {



// 判断当前节点的子节点是否还存在 如果存在则转移到渲染树中



if (currentReport.children.length > 0) {



const transformMonth = currentReport.children.splice(0, 1)



this.treeList[this.treeList.length - 1].children.push(



transformMonth[0]



)



// 如果不存在 则寻找下一树节点进行复制 同时复制下一节点的第一个子节点 当然如果寻找不到下一树节点则终止翻页



} else if (this.treeList.length < this.backTreeList.length) {



const nextTree = this.backTreeList[this.treeList.length]



const nextTansformTree = nextTree.children.splice(0, 1)



this.treeList.push({



id: nextTree.id,



children: nextTansformTree



})



}



}



}



}

4. 逻辑细节

从上面代码可以看到，翻页的操作是树copy的操作，将备份树的子节点转移到渲染树中

扩展思路

这个方法可以进行封装，将每次复制的节点数目和每次复制的子节点数目作为传参，一次可复制多个节点，这里就不做展开

前言：

大家好，我是小瑜。最近在网上看到了东方甄选和董宇辉的小作文事件，我也一直是众多吃瓜群众的一员，看完后董宇辉俞敏洪的联合直播，心中也有很多感触。

董宇辉老师说，一放假，就喜欢往家里跑，因为接近土地可以感到踏实。一个千万网红这种纯粹质朴的精神着实让人很贴切。

特别是董老师的另外一番话：你必须人生中有一段经历是自己走过去的。你充满了痛苦，然后充满了孤独，但这个东西叫做成长，好的生活和幸福的经历是不能带来成长的，所以能见到很多人，四五十岁看着还很幼稚，说明他从来没有受到苦，能让你成长的东西，就是让你反思的东西，因为在历史的长河中进化是痛苦的，逼不得已，人才会进步很成长，所以成长都不快乐。但同时也恭喜你一直在成长。

在学习以及编写这篇文章的时候，我也是痛苦的，同时也有所收获。接下来给大家分享this指向以及手写call、apply、bind。

在这之间给大家简单举几个例子说明下this指向的不同

普通函数调用

// 谁调用就是谁, 直接调用window

function sayHi() {

  console.log(this); // window

}

sayHi()  // === window.sayHi()

对象中的方法调用

const obj = {

  name: 'zs',

  objSayHi() {

    console.log(this) // obj

    setTimeout(() => {

     console.log(this, 'setTimeout'); // obj

      }, 1000),

    function inner() {

      console.log(this); // window

    }

    inner() 

  },

  qwe: () => console.log(this) // window

}

obj.objSayHi()

obj.qwe()

obj.objSayHi() => obj

• 因为是 **obj **对象调用，所以 **this **指向 **obj **这个对象

obj.qwe() => window

• 对于箭头函数 qwe，它捕获的是定义时外部的 this 上下文。在浏览器中全局范围内的箭头函数 qwe 的 this 指向的是全局对象 window（或者是全局的 this，具体取决于执行上下文）。

inner() => window

• inner() 函数是通过常规函数声明方式定义的。在 JavaScript 中，常规函数声明方式中的 this 在严格模式下指向 undefined，而在非严格模式下（例如浏览器环境中），this 指向全局对象（在浏览器中通常是 window 对象）。因此，当 inner() 函数在 objSayHi() 方法内部被调用时，其 this 指向全局对象 window。

setTimeout => obj

• objSayHi 方法中，setTimeout 中的回调函数使用了箭头函数。箭头函数内部的 this 会捕获最近的普通函数（非箭头函数）的 this 值，也就是 objSayHi 被调用时的 this。因此，setTimeout 中的箭头函数捕获到的 this 值指向的是 obj 对象。

总结：浏览器环境中, 谁调用this指向谁，但是箭头函数的this义是外部的 this 上下文。通过常规函数声明方式定义this指向window。其他关于this指向可以参考这张图

修改this指向

call

第1个参数为this，第2-n为传入该函数的参数

function myThis1(name, age) {

    console.log(this);

    console.log(name);

    console.log(age);

   }

const obj = {

    name: 'zs',

    age: 18

}

myThis1.call(obj, 'ls', 20) // {name:"zs",age:18} ls 18

apply

第1个参数为this，第2-n已数组的方式传递

function myThis1(name, age) {

    console.log(this);

    console.log(name);

    console.log(age);

   }

const obj = {

    name: 'zs',

    age: 18

}

myThis1.apply(obj, ['王五', 18]) // {name:"zs",age:18} 王五 18

bind

bind() 方法创建一个新函数，当调用该新函数时，它会调用原始函数并将其 this 关键字设置为给定的值，同时，还可以传入一系列指定的参数

function myThis1(name, age) {

    console.log(this);

    console.log(name);

    console.log(age);

   }

const obj = {

    name: 'zs',

    age: 18

}



![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/92cfe20fc6374374bacf97bcc3d31ac6~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=814&h=308&s=145955&e=png&b=fafafa)

const fn = myThis1.bind(obj, '赵六',30)

fn()  //  {name:"zs",age:18} 赵六 30

手写call函数

要求实现

const obj = {

  name: 'zs',

  age: 20

}

function myFn(a, b, c, d, e) {

  console.log(`大家好,我的名字叫${this.name} 我今年${this.age}岁了`, a, b, c, d, e);

}

myFn.myCall(obj, 1, 2, 3, 4, 5)

简单思路：

实现思路1：通过函数原型的方式，给原型添加 myCall 方法，这样通过原型链就可以使用

Function.prototype.myCall = function () {

  console.log('myCall被调用了');

}

myFn.myCall()

实现思路2：在myCall调用的时候将obj传入到函数中，并根据谁调用this就指向谁的原则给对象添加this方法并执行

首先可以打印看一下thisArg，this 分别是什么

const obj = {

  name: 'zs',

  age: 20

}

Function.prototype.myCall = function (thisArg) {

  console.log('myCall被调用了',thisArg，this);

}

function myFn(a, b, c, d, e) {

  console.log(`大家好,我的名字叫${this.name} 我今年${this.age}岁了`, a, b, c, d, e);

}

myFn.myCall(obj)

很明显 **thisArg 就是 obj **对象 而 this就是 myFn 这个函数，那么就可以根据谁调用this就指向谁的原则，将obj这个对象也就是 **thisArg **添加 myCall 方法 = this

  Function.prototype.myCall = function (thisArg) {

    console.log('myCall被调用了', thisArg, this);

    thisArg.myCall = this

    thisArg.myCall()

}

function myFn(a, b, c, d, e) {

    console.log(`大家好,我的名字叫${this.name} 我今年${this.age}岁了`, a, b, c, d, e);

 }

const obj = {

      name: 'zs',

      age: 20

 }

myFn.myCall(obj, 1, 2, 3, 4, 5)

此时就发现，this已经成功指向了这个obj对象，但是还差参数没有传递，接下去就去实现

实现思路3：利用剩余参数加展开运算符传入参数

  Function.prototype.myCall = function (thisArg,...args) {

    console.log('myCall被调用了', thisArg, this);

    thisArg.myCall = this

    thisArg.myCall(...args)

}

function myFn(a, b, c, d, e) {

    console.log(`大家好,我的名字叫${this.name} 我今年${this.age}岁了`, a, b, c, d, e);

 }

const obj = {

      name: 'zs',

      age: 20

 }

myFn.myCall(obj, 1, 2, 3, 4, 5)