[译] 使用 TypeScript 开发 React Hooks

原文： www.toptal.com/react/react…

React hooks 在 2019 年二月被引入，以改善代码可读性。本文将探讨如何将其和 TypeScript 协同使用。

在 hooks 以前，有两种风格的 React 组件：

• 处理状态的 类组件（Classes）
• 彻底由其 props 定义的 函数式（Functional）组件

一种常见用法是，由前者构建复杂的容器（Container）组件，然后者负责简单些的展现型（Presentational）组件。

何为 React Hooks ？

容器组件负责状态（state）管理，以及在本文中被称为“反作用（side effects）”的远端请求。状态将经由 props 传播到子组件。

但随着代码的增加，函数式组件也大有取代类组件成为容器的意思。

将函数式组件升级为状态庞杂的容器却是谈不上痛苦，只是费时费力。此外，严格区分所谓容器和展现组件也不那么被看重了。

Hooks 能够很好地兼顾， 能让代码既通用，又拥有几乎全部的优势。这里有个例子，用来演示如何向一个处理报价签署的组件中增添一个本地状态：

// 在一个本地状态中放置签名，并在签署状态改变时切换签名
function QuotationSignature({quotation}) {
   const [signed, setSigned] = useState(quotation.signed);
   useEffect(() => {
       fetchPost(`quotation/${quotation.number}/sign`)
   }, [signed]); // 签署状态改变时，反作用将被触发

   return <>
       <input type="checkbox" checked={signed} 
            onChange={() => {setSigned(!signed)}}/>
       Signature
   </>
}
复制代码

还有个利好不得不说 -- 虽然相比于 TypeScript 在 Angular 中的丝滑编码，到了 React 中总被诟病臃肿难用；但 用 TypeScript 搭配 React hooks 却变为了一种愉悦的体验。

旧 React 里的 TypeScript

TypeScript 由微软设计并沿着 Angular 的路径一路进发，而彼时 React 开发出的 Flow 已然式微。在 React 类组件中编写原生 TypeScript 着实痛苦，由于 React 开发者不得不一样时对 props 和 state 定义类型，即使两者的许多属性是相同的。

按原来的方式来讲，先得有一个 Quotation 类型，用来管理某些 CRUD 组件的 state 和 props。并在其相关的 state 中，建立一个 Quotation 类型的属性，以及指示已签署或未签署的状态。

interface QuotationLine {
  price: number
  quantity: number
}

interface Quotation{
   id: number
   title: string;
   lines: QuotationLine[]
   price: number
}

interface QuotationState{
   readonly quotation: Quotation;
   signed: boolean
}

interface QuotationProps{
   quotation: Quotation;
}

class QuotationPage extends Component<QuotationProps, QuotationState> {
	 // ...
}
复制代码

可是设想一下，在新建某个报价时咱们面临的状况，也就是 QuotationPage 还没有向服务器成功请求到一个 id 时：以前定义的 QuotationProps 将没法获知这个关键的数字值 -- 不完整的数据也没法被 Quotation 类型 精确 匹配。咱们可能不得不在 QuotationProps 接口中声明更多的代码：

interface QuotationProps{
   // 除去 id 以外 Quotation 中的全部属性：
   title: string;
   lines: QuotationLine[]
   price: number
}
复制代码

咱们拷贝了除去 id 以外的全部属性搞出一个新类型。这...让我回忆起在 Java 中，被不得不编写的一大堆 DTO （译注：Data Transfer Object，数据传输对象 -- 一种不包含业务逻辑的简单容器，其行为限于内部一致性检查和基本验证等） 所支配的恐惧。

为了克服这种痛苦，咱们得在 TypeScript 的知识上补补课了。

TypeScript 结合 hooks 的好处

经过使用 hooks，咱们就能够摒弃以前的 QuotationState -- 能够将其拆分为不一样的两部分：

// ...

interface QuotationProps{
   quotation: Quotation;
}
function QuotationPage({quotation}:QuotationProps) {
   // 译注：由两个 useXXX 函数分摊了以前接口中的两个属性
   const [quotation, setQuotation] = useState(quotation);
   const [signed, setSigned] = useState(false);
   
   // ...
}
复制代码

经过拆分状态，就省去了明确建立新的接口。本地状态类型每每能推导出默认的状态值。

由于 hooks 组件就是函数，故能够编写返回 React.FC<Props> 类型（译注：FC 即 function components）的相同组件函数。这样的函数显式声明了其函数式组件的返回类型，并明确了 props 类型。

const QuotationPage: FC<QuotationProps> = ({quotation}) => {
   const [quotation, setQuotation] = useState(quotation);
   const [signed, setSigned] = useState(false);
   
   // ...
}
复制代码

显然，在 React hooks 中使用 TypeScript 比在类组件中容易。而且由于强类型对于代码安全是个有力的保障，若是你的新项目中用了 hooks 就应该考虑采用 TypeScript 了。

适配 hooks 的 TypeScript 特性

在以前的 React hooks TypeScript 例子中，对于 QuotationProps 接口中的属性如何使用、使用哪些，还是不甚了了、很有不便。

TypeScript 其实提供了很多“工具方法”，以便在 React 中描述接口时有效“降噪”。

• Partial<T> : T 类型全部键的任意子集
• Omit<T, 'x'> : 除 x 以外的 T 类型全部键
• Pick<T, 'x', 'y', 'z'> : 从 T 类型中明确拾取 x, y, z 键

在咱们的用例中，能够用 Omit<Quotation, 'id'> 的形式来将 id 排除在 Quotation 类型以外。结合 type 关键字反手就能甩出一个新类型。

Partial<T> 和 Omit<T> 并不存在于 Java 等大部分强类型语言中，但常在前端开发中以各类方式大展身手。它们简化了类型定义的负担。

type QuotationProps = Omit<Quotation, id>;
function QuotationPage({quotation}: QuotationProps){
   const [quotation, setQuotation] = useState(quotation);
   const [signed, setSigned] = useState(false);
   
   // ...
}
复制代码

固然，或许也能够用 extends 更清晰地区分出持久化类型等：

interface Quote{
   title: string;
   lines: QuotationLine[]
   price: number
}

interface PersistedQuote extends Quote{
  id: number;
}
复制代码

这样在处理相关属性时，也简化了常见的 if 或 undefined 问题。

慎用 Partial<T>，它基本不会带来任何保障。

Pick<T, ‘x’|’y’> 是另外一种不用声明新接口就能随时定义新类型的方式。若是一个组件只须要简单编辑报价标题的话：

type QuoteEditFormProps = Pick<Quotation, 'id'|'title'>
复制代码

或直接在行内声明：

function QuotationNameEditor({id, title}: Pick<Quotation, 'id'|'title'>){ ...}
复制代码

别怀疑，我但是领域驱动设计（DDD - Domain Driven Design）的铁杆拥趸。我并非懒得为了声明个新接口而懒得多写两行 -- 须要精确描述领域内命名时，我会使用接口；而出于保证本地代码正确性、降噪的目的，我就使用这些 TS 工具语法。

React Hooks 的其余益处

React 团队始终将 React 视为一个函数式框架。过去他们使用类组件以处理自身状态，如今有了 hooks 这种容许一个函数跟踪组件状态的技术。

interface Place{
  city: string,
  country: string
}
const initialState: Place = {
  city: 'Rosebud',
  country: 'USA'
};
function reducer(state: Place, action): Partial<Place> {
  switch (action.type) {
    case 'city':
      return { city: action.payload };
    case 'country':
      return { country: action.payload };
  }
}
function PlaceForm() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <form>
      <input type="text" name="city" 
        onChange={(event) => {
          dispatch({ type: 'city', payload: event.target.value})
        }}
        value={state.city} />
      <input type="text" name="country"   
        onChange={(event) => {
          dispatch({type: 'country', payload: event.target.value })
        }}
        value={state.country} />
   </form>
  );
}
复制代码

这就是一个安全使用 Partial 的良好用例。

尽管 reducer 函数会被屡次执行，但相关的 useReducer hook 将只被建立一次。

经过 天然而然地 将 reducer 函数定义在组件以外，代码能够被分割成多个独立的函数，而不是都集中在一个类中并共同围绕着其内部状态。

这对可测试性大有裨益 -- 某些函数只处理 JSX，其余一些只处理业务逻辑，等等。

你（几乎）再也不须要高阶组件（HOC - Higher Order Components）了。渲染属性（render props）模式更易于编写函数式组件。

这样一来，阅读代码变得更容易了。代码再也不是连绵混杂的 类/函数/模式，而仅仅是函数的集合。然而，由于这些函数并未附加到一个对象中，对它们命名可能有点难。

TypeScript 还是 JavaScript

JavaScript 的乐趣在于你能以任何方式摆弄你的代码。加上 TypeScript 后，你仍能够用 keyof 访问对象的全部键，也能使用类型联合建立出晦涩难搞的某些东西 -- 怕了怕了。

要确保你的 tsconfig.json 设置了 "strict":true 选项。在项目动工前就检查它，不然你将不得不重构不少东西！

对于以何种程度类型化代码是有争议的。你能够手动定义全部东西，也可让编译器推断出类型。这取决于 linter 工具的配置和团队约定。

同时，你仍会遇到运行时错误！TypeScript 比 Java 简单，而且回避了泛型的协变/逆变问题。

在下例中，有一个 Animal 列表，以及一个相同的 Cat 列表。

interface Animal {}

interface Cat extends Animal {
  meow: () => string;
}

const duck = { age: 7 };
const felix = {
  age: 12,
  meow: () => "Meow"
};

const listOfAnimals: Animal[] = [duck];
const listOfCats: Cat[] = [felix];

function MyApp() {

  const [cats , setCats] = useState<Cat[]>(listOfCats);
  // 问题1：再次被使用的 listOfCats 声明为了一个 Animal[]
  const [animals , setAnimals] = useState<Animal[]>(listOfCats)
  const [animal , setAnimal] = useState(duck)

  return <div onClick={()=>{
      animals.unshift(animal) // 问题2：指鸭为猫
      setAnimals([...animals]) // 形成 dirty forceUpdate
    }}>
    The first cat says {cats[0].meow()} // 不言而喻
  </div>;
}
复制代码

糟糕的是，因为分别用 Cat[] 和 Animal[] 两种泛型声明了 listOfCats，然后把 listOfAnimals 中的 duck 错误地压入了第二次声明为 Animal[] 的 listOfCats 数组 -- 仅从 TS 静态语法上看是一个 Animal 进入了一个 Animal[]，但这就让随后对第一次声明为 Cat[] 的 listOfCats 元素调用发生了运行时错误。

TypeScript 只有一种泛型的简单 双变（bivariant） 实现，以供 JS 开发者采用。若是对变量命名得当，就能很大程度上避免指鸭为猫。

同时，存在向 TS 中增长 in 和 out 约束的提案（ https://github.com/microsoft/TypeScript/issues/10717），以支持协变和逆变。

--End--

查看更多前端好文
请搜索 fewelife 关注公众号

转载请注明出处