snakeUni

import React from "react";
import { Link } from "react-router-dom";

export function createResource(getPromise) {
  let cache = {};
  let inflight = {};
  let errors = {};

  function load(key) {
    inflight[key] = getPromise(key)

snakeUni

const bypass = [
  // function names to avoid logging
];
const collapsed = [
  // function names to groupCollapsed
];

module.exports = function(babel) {
  const { types: t } = babel;
  const wrapFunctionBody = babel.template(`{

snakeUni

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

snakeUni

import React, { useMemo } from "react";
import useSubscription from "./useSubscription";

// In this example, "source" is an event dispatcher (e.g. an HTMLInputElement)
// but it could be anything that emits an event and has a readable current value.
function Example({ source }) {
  // In order to avoid removing and re-adding subscriptions each time this hook is called,
  // the parameters passed to this hook should be memoized.
  const subscription = useMemo(
    () => ({

snakeUni

Hooks vs Class

React 释放 hooks 已经半年了，从 hooks 刚刚释放的时候我就开始关注，并且就开始去尝试使用它。 从释放到现在 hooks 刚过不少， 内部源码至少改了两三次， 那为什么要写这篇文章呢 ？ 是因为一次偶然的事情引发的。 有一天渊虹老哥抱着电脑对我说， 你看我这个表单的提交时间就是在调用 onSubmit 的时候有点延迟啊， 这是为什么呀? 我试了一下果然是这样， 很奇怪了，为什么会这样呢 ? 于是我想到的第一个问题就是难道我把同步当做异步处理导致的？ 还是有可能的啊，于是我在群里问了这样的一个问题 于是我就在第二天跑了一下，试试同步当做异步处理的话，会造成多少的延迟。当数量小于100个时候，简单的函数同步异步时间基本一致，1000个的时候时间就有一些小的差距了， 10000 个的时候差距非常明显， 所以必要的时候，同步还是同步，不要当做异步来处理了, 那一个 form 内部超过 100 个校验函数基本不可能，所以这个方面我就忽略了, 那会不会是另外一种可能呢？

render 时间长且次数多导致的延迟

再一次分析了渊虹老哥的代码，发现在提交表单的时候，render 了四次，于是我去查了下源码，发现这四次分别是，校验设置错误 => 设置提交状态 => 设置表单是否有效 => 设置提交次数, 然后在调用 onSubmit， 哎呀这个地方有有待修改的，比如可以改成这样 设置提交状态 => 如果有效，调用 onSubmit 在设置有效状态和提交次数。 否则在 设置错误和状态， 这样呢就能保证 onSubmit 的提交只有一次 setState 的操作，看下代码的截图