Solid 作者从 React 中学到最重要的是什么?

开发 前端
本文存在的意义,是阐述一个观点 —— 这些规范之所以存在,是为了共同实现「局部思考」的理念。而这一理念,才是前端框架可维护性、可读性的来源。

大家好,我卡颂。

前端界有句玩笑话 —— 「React 一点都不 react,Solid 才应该叫 React」。

作为一款「借鉴了很多 React 特性」的前端框架,截止目前,Solid已经有 29.6kstar。显然,他已经得到了社区的认可。

前段时间,Solid的作者「Ryan Carniato」在博文Thinking Locally with Signals[1]中提到 —— SolidReact中学到的最重要的东西,不是JSX虚拟DOM,而是一个被称为「局部思考」(Locality of Thinking)的概念。

本文就来聊聊这个对前端开发影响深远的理念。

局部思考是什么?

当我们新入职一家公司,在熟悉项目代码阶段,领导通常会分配给我们一些小需求,帮助我们快速熟悉项目代码。

这个过程是如此自然,以至于我们都忽视了一个重要问题 —— 为什么在一个庞大的项目代码库中,即使不熟悉代码,也能轻松修改一些小功能?

答案是 —— 「局部思考」理念在发挥作用。

「局部思考」是指你可以不看其他代码,只通过一个组件的代码就能理解它的行为。这种思考方式对代码的可维护性和可读性有着重大影响。

首先,在大型项目中,代码的「可维护性」至关重要。如果每次修改都需要理解整个代码库,那么这个项目可能会很快变得难以维护。

其次,从「可读性」的角度来看,如果代码的可读性好,那么新的开发人员可以更快地理解和开始他们的工作。

通过「局部思考」,可以使代码更易读、可维护性更高。试想,这不正是「使用框架开发」相比于「使用 jQuery 开发」的优势么?至于框架的其他特性(比如虚拟DOM细粒度更新Hooks...)都是在「局部思考」的基础上发展出来的。

可以说,「局部思考」是「框架开发」这种工作模式的基石。

如何实现局部思考

假设项目中有如下代码,你能保证结果是true么:

const obj = {}
someFunction(obj)

// 结果是 true 么?
console.log(obj.value === undefined)

要想知道结果,必须看someFunction函数的内部实现。如果项目中大量充斥了上面这样的代码,对可读性、可维护性简直是灾难。

「局部思考」理念的提出就是为了解决上述问题。要实现「局部思考」,有四个重要因素:

  • 单向数据流
  • 读写分离
  • 显式突变
  1. 组件隔离

单向数据流

数据应该只在一个方向上流动。这样可以保证数据的来源和使用是一致的,使得代码行为更可预测,减小了出现bug的可能性。

考虑如下Solid代码,数据只从父组件流向子组件。子组件只读取数据,而不能改变它:

// 父组件内
const [count, setCount] = createSignal(0);
<ChildComponent count={count()} />

// 子组件内
const ChildComponent = ({ count }) => {
  // count是只读的
  return <div>{count}</div>
}

读写分离

读取数据和修改数据应该是两个独立的操作。这样可以降低代码的复杂度,使得阅读和理解代码更简单。

考虑如下Solid代码,SomeComponent通过title()读取值,通过setTitle修改值。这种分离使得我们可以更好地理解状态何时变化。

// [读, 写]
const [title, setTitle] = createSignal("title");

// `SomeComponent`不能改变`title`
<SomeComponent title={title()} />

// 现在`SomeComponent`可以更新title
<SomeComponent title={title()} updateTitle={setTitle} />

在Svelte中,状态(或者叫signal)只能「按值传递」,所以下面SomeComponent即使接收title作为props,也无法直接修改他。

要修改他,需要执行updateTitle方法(方法内部闭包中的title是signal,可以响应更新)。这也是一种「读写分离」的实现。

let title = $state("title")

// `SomeComponent`不能改变`title`
<SomeComponent title={title} />

// 现在`SomeComponent`可以更新title
<SomeComponent title={title} updateTitle={(v) => title = v} />

显式突变

所有的数据变化应该是显式的,而不是在背后默默发生。这样更容易跟踪数据的变化。考虑如下Solid代码:

// 定义状态
const [count, setCount] = createSignal(0);

// 显式改变状态
setCount(count() + 1);

是不是一下就想到了React中的useState呢?没错,其实不止是useState,在ClassComponent的this.setState也是遵循同样的原则。

组件隔离

每个组件应该只关心自己的状态和逻辑,而不是其他组件的。这样可以保证组件之间的独立性,降低耦合度,使得代码更易于维护。

总结

如果你觉得以上的介绍一点技术含量都没有,那是再自然不过的事。因为这些原则都是React最基本的使用规范。

本文存在的意义,是阐述一个观点 —— 这些规范之所以存在,是为了共同实现「局部思考」的理念。而这一理念,才是前端框架可维护性、可读性的来源。

按照这个思路去思考,就能明白很多React特性的用意,比如:

  • 为什么函数组件替代了类组件。
  • 为什么会出现useEffect这个Hook。
  • 为什么ref不能跨函数组件传递。

这些特性的背后,都体现了「局部思考」的理念。

参考资料

[1]Thinking Locally with Signals:https://dev.to/this-is-learning/thinking-locally-with-signals-3b7h。

责任编辑:姜华 来源: 魔术师卡颂
相关推荐

2021-03-09 09:55:02

Vuejs前端代码

2021-10-11 09:55:58

Facebook业务中断网络安全

2013-08-19 12:46:27

2023-11-24 13:24:14

CIOOptus

2021-09-08 17:36:58

程序员技能开发者

2020-12-31 10:47:03

开发Vuejs技术

2016-01-18 10:06:05

编程

2020-07-07 10:38:11

首席信息官IT领导者经验教训

2020-07-07 10:40:45

CIO首席信息官IT

2022-12-12 11:08:07

数字化转型企业

2024-06-13 15:59:30

2020-01-08 14:32:06

物联网黑客网络安全

2024-04-07 14:11:42

ITGenAI

2020-05-19 13:46:33

勒索软件信息安全攻击

2018-08-14 05:34:19

2009-05-14 10:40:11

网络工程师能力

2022-03-27 09:06:04

React类型定义前端

2010-10-12 11:06:07

招聘

2015-05-06 14:36:56

CIO云计算风险云迁移

2019-07-23 07:48:38

机器学习商业深度学习
点赞
收藏

51CTO技术栈公众号