不同团队编写进去的 React 代码也不尽相同，程度有个有高下，就像十个读者就有十种哈姆雷特，然而以下八点可能是你编写 React 代码的基本准则。
遵循繁多目标组件哲学，防止过于简单的多行组件，并尽可能地将组件合成。

假如咱们有一个简略的 <userCard/> 组件，此组件的惟一用处是接管一个 user 对象并显示相应的用户数据。

代码如下：

import React from 'react';
import propsTypes from 'props-types';
const UserCard = ({user}) => {
  return (
    <ul>
      <li>{user.name}</li>
      <li>{user.age}</li>
      <li>{user.email}</li>
    </ul>
  )
}
UserCard.propsTypes = {user: propsTypes.object}
UserCard.defaultTypes = {user: {}
}

这个组件须要一个 user props 并且它是组件的惟一数据源，然而这个 props 不是必须的（没有设置 isRequired），所以设置了一个默认值为 {}，以防止 Can not access property‘name’of… errors 等谬误。

那么，如果没有为 <UserCard> 组件在期待渲染时提供一个回退值（fallback），并且 UserCard 没有任何数据也没有任何逻辑运行，那么就没有理由出现这个组件。

那么，props 什么时候是必须的，什么时候不是必须的呢？

有时候你只须要问问本人什么才是最有意义的。

假如咱们有一个转换货币的组件 <CurrencyConverter/>，它有三个 props：

• value – 咱们要转换的数值。
• givenCurrency – 咱们正在转换的货币。
• targetCurrency – 咱们要转换成的货币。

然而，如果咱们的 value 值有余，那么进行任何转换都毫无意义，那时基本不须要出现组件。

因而，value props 必定是必须的。

二、条件在父组件中出现

咱们有时候在一个子组件中常常会看到相似如下代码：

import React, {useState} from "react";
import PropTypes from "prop-types";
// 子组件
export const UserCard = ({user}) => {const keys = Object.keys(user)
  return (
    keys.length ?
      <ul>
        <li>{user.name}</li>
        <li>{user.age}</li>
        <li>{user.email}</li>
      </ul>
    : "No Data"
  );
};

咱们看到一个组件带有一些逻辑，却徒劳地执行，只是为了显示一个 spinner 或一条信息。

针对这种状况，请记住，在父组件外部实现此操作总是比在组件自身外部实现更为洁净。

按着这个准则，子组件和父组件应该像这样：

import React, {useState} from "react";
import PropTypes from "prop-types";
// 子组件
export const UserCard = ({user}) => {
  return (
    <ul>
      <li>{user.name}</li>
      <li>{user.age}</li>
      <li>{user.email}</li>
    </ul>
  );
};
UserCard.propTypes = {user: PropTypes.object.isRequired};
// 父组件
export const UserContainer = () => {const [user, setUser] = useState(null);
  // do some apiCall here
  return (
    <div>
      {user && <UserCard user={user} />}
    </div>
  );
};

通过这种形式，咱们将 user 初始化为 null，而后简略的运行一个 falsy 检测，如果 user 不存在，!user 将返回 true。

如果设置为 {} 则不然，咱们必须通过 Object.keys() 查看对象 key 的长度，通过不创立新的对象援用，咱们节俭了一些内存空间，并且只有在取得了所需的数据之后，咱们才渲染子组件 <UserCard/>。

如果没有数据，显示一个 spinner 也会很容易做到。

export const UserContainer = () => {const [user, setUser] = useState(null); 
  // do some apiCall here
  return (
    <div>
      {user ? <UserCard user={user} /> : 'No data available'}
    </div>
  );
};

子组件 <UserCard/> 只负责显示用户数据，父组件 <UserContainer/> 是用来获取数据并决定出现什么的。这就是为什么父组件是显示回退值（fallback）最佳地位的起因。

三、不满足时，及时 return

即便咱们应用的是失常的编程语言，嵌套也是一团糟，更不用说 JSX（它是 JavaScript、HTML 的混合体）了。

你可能常常会看到应用 JSX 编写的相似的代码：

const NestedComponent = () => {
  // ...
  return (
    <>
      {!isLoading ? (
        <>
          <h2>Some heading</h2>
          <p>Some description</p>
        </>
      ) : <Spinner />}
    </>
  )
}

该怎么做才是更正当的呢？

const NestedComponent = () => {
  // ...
  if (isLoading) return <Spinner />
  return (
    <>
      <h2>Some heading</h2>
      <p>Some description</p>
    </>
  )
}

咱们解决 render 逻辑时，在解决是否有可用的数据，页面是否正在加载，咱们都能够抉择提前 return。

这样咱们就能够防止嵌套，不会把 HTML 和 JavaScript 混合在一起，而且代码对于不同技术水平或没有技术背景的人来说也是可读的。

四、在 JSX 中尽量少写 JavaScript

JSX 是一种混合语言，能够写 JS 代码，能够写表达式，能够写 HTML，当三者混合起来后，应用 JSX 编写的代码可读性就会差很多。

尽管有教训的人能够了解组件外部产生了什么，但并不是每个人都能了解。

const CustomInput = ({onChange}) => {
  return (
    <Input onChange={e => {const newValue = getParsedValue(e.target.value);
      onChange(newValue);
    }} />
  )
}

咱们正在解决一些内部对 input 的一些输出，应用自定义处理程序解析该输出 e.target.value，而后将解析后的值传给 <CustomInput/> 组件接管的 onChange prop。尽管这个示例能够失常工作，然而会让代码变得很难了解。

在理论我的项目中会有更多的元素和更简单的 JS 逻辑，所以咱们将逻辑从组件中抽离进去，会使 return() 更清晰。

const CustomInput = ({onChange}) => {const handleChange = (e) => {const newValue = getParsedValue(e.target.value);
    onChange(newValue);
  };
  return (<Input onChange={handleChange} />
  )
}

当在 render 中返回 JSX 时，不要应用内联的 JavaScript 逻辑。

五、userCallback & userEffect

随着 v16.8 Hooks 问世后，人们开始大量应用函数组件，当应用函数进行编写组件时，如果须要在外部执行 API 接口的调用，须要用到 useEffect 生命周期钩子。

useEffect 用于解决组件中的 effect，通常用于申请数据，事件处理，订阅等相干操作。

在最后版本的文档指出，避免 useEffect 呈现有限循环，须要提供空数组 [] 作为 useEffect 依赖项，将使钩子只能在组件的挂载和卸载阶段运行。因而，咱们会看到在很多应用 useEffect 的中央将 [] 作为依赖项传入。

应用 useEffect 呈现有限循环的起因是，useEffect 在组件 mount 时执行，但也会在组件更新时执行。因为咱们在每次申请数据之后基本上都会设置本地的状态，所以组件会更新，因而 useEffect 会再次执行，因而呈现了有限循环的状况。

然而，这种解决形式就会呈现 react-hooks/exhaustive-deps 规定的正告，因而代码中经常会通过正文疏忽此正告。

// eslint-disable-next-line react-hooks/exhaustive-deps 

import React, {useState, useEffect} from 'react'
import {fetchUserAction} from '../api/actions.js'
const UserContainer = () => {const [user, setUser] = useState(null);
  
  const handleUserFetch = async () => {const result = await fetchUserAction();
    setUser(result);
  };
  
  useEffect(() => {handleUserFetch();
    // 疏忽正告
    // eslint-disable-next-line react-hooks/exhaustive-deps 
  }, []);
  
  if (!user) return <p>No data available.</p>
  
  return <UserCard data={user} />
};

最后，很多人认为这个正告毫无意义，从而抉择进行疏忽，而不去试图摸索它是如何产生的。

其实，有些人没有意识到，handleUserFetch() 办法在组件每次渲染的时候都会从新创立（组件有多少次更新就会创立多少次）。

对于 react-hooks/exhaustive-deps 具体的探讨，能够看下这个 issue。

useCallback 的作用在于利用 memoize 缩小有效的 re-render，来达到性能优化的作用。

这就是为什么咱们须要在 useEffect 中调用的办法上应用 useCallback的起因。通过这种形式，咱们能够避免 handleUserFetch() 办法从新创立（除非其依赖项发生变化)，因而这个办法能够用作 useEffect 钩子的依赖项，而不会导致有限循环。

上边的例子应该这样重写:

import React, {useState, useEffect, useCalllback} from 'react'
import {fetchUserAction} from '../api/actions.js'
const UserContainer = () => {const [user, setUser] = useState(null);
  
  // 应用 useCallback 包裹
  const handleUserFetch = useCalllback(async () => {const result = await fetchUserAction();
    setUser(result);
  }, []);
  
  useEffect(() => {handleUserFetch();
  }, [handleUserFetch]); /* 将 handleUserFetch 作为依赖项传入 */
  
  if (!user) return <p>No data available.</p>
  
  return <UserCard data={user} />
};

咱们将 handleUserFetch 作为 useEffect 的依赖项，并将它包裹在 useCallback 中。如果此办法应用内部参数，例如 userId (在理论开发中，可能心愿获取特定的用户)，则此参数能够作为 useCallback 的依赖项传入。只有 userId 发生变化时，依赖它的 handleUserFetch 才重写扭转。

六、抽离独立逻辑

假如咱们在组件中有一个办法，它能够解决组件的一些变量，并为咱们返回一个输入。

例如：

const UserCard = ({user}) => {const getUserRole = () => {const { roles} = user;
    if (roles.includes('admin')) return 'Admin';
    if (roles.includes('maintainer')) return 'Maintainer';
    return 'Developer';
  }
  
  return (
    <ul>
      <li>{user.name}</li>
      <li>{user.age}</li>
      <li>{user.email}</li>
      <li>{getUserRole()}</li>
    </ul>
  );
}

这个办法和前一个例子中的办法一样，在组件每次渲染时都会从新创立，（然而没必要应用 useCallback 进行包裹，因为它没有被作为一个依赖项传入）。

组件外部定义的许多逻辑能够从组件中抽离，因为它的实现并不真正与组件相干。

改良后的代码：

const getUserRole = (roles) => {if (roles.includes('admin')) return 'Admin';
  if (roles.includes('maintainer')) return 'Maintainer';
  return 'Developer';
}
const UserCard = ({user}) => {
  return (
    <ul>
      <li>{user.name}</li>
      <li>{user.age}</li>
      <li>{user.email}</li>
      <li>{getUserRole(user.roles)}</li>
    </ul>
  );
}

通过这种形式，能够在一个独自的文件中定义函数，并在须要时导入，进而可能会达到复用的目标。

晚期将逻辑从组件中形象进去，能够让咱们领有更简洁的组件和易于重用的实用函数。

七、不要应用内联款式

CSS 作用域在 React 中是通过 CSS-in-JS 的计划实现的，这引入了一个新的面向组件的款式范例，它和一般的 CSS 撰写过程是有区别的。另外，尽管在构建时将 CSS 提取到一个独自的样式表是反对的，但 bundle 里通常还是须要一个运行时程序来让这些款式失效。当你可能利用 JavaScript 灵活处理款式的同时，也须要衡量 bundle 的尺寸和运行时的开销。– 来自 Vue 官网

以前，网页开发有一个准则，叫做「关注点拆散」，次要是以下三种技术拆散：

• HTML 语言：负责网页的构造，又称语义层。
• CSS 语言：负责网页的款式，又称
• JavaScript 语言：负责网页的逻辑和交互，又称逻辑层或交互层。

对 CSS 来说，就是不要写内联款式（inline style），如下：

<div style="width: 100%; height: 20px;">

然而组件化（Vue、React）风行当前，突破了这个准则，它要求把 HTML、CSS、JavaScript 写在一起。

应用 React 编写款式能够这么做：

const style = {fontSize: "14px"}
const UserCard = ({user}) => {
  return (<ul style={style}>
      <li>{user.name}</li>
      <li>{user.age}</li>
      <li>{user.email}</li>
      <li>{getUserRole(user.roles)}</li>
    </ul>
  );
}

React 这么做有利于组件的隔离，每个组件蕴含了所有须要用到的代码，不依赖内部，组件之间没有耦合，很不便复用。

这里，本文不倡议在 React 中应用内联款式基于两点：

1. 他会让你的 HTML 构造变得臃肿。
2. 如果款式过多，保护起来很麻烦，无奈通过内部批改 CSS。

const style1 = {fontSize: "14px"}
const style2 = {
  fontSize: "12px",
  color: "red"
}
const style = {...}
const UserCard = ({user}) => {
  return (<ul style={style}>
      <li style={style2}>{user.name}</li>
      <li style={color: "#333"}>{user.age}</li>
      <li style={color: "#333"}>{user.email}</li>
      <li style={color: "#333"}>{getUserRole(user.roles)}</li>
    </ul>
  );
}

看到这里，有人可能会反驳：「你能够应用 props 有条件地对 CSS 内嵌款式进行款式化」，这是可行的，然而，你的组件不应该只有 10 个解决 CSS 的 props，而不做其余事件。

如果非要在组件中编写 CSS，倡议应用 style-components CSS-in-JS 库。

styled-components 编写的组件款式存在于 style 标签内，而且选择器名字是一串随机的哈希字符串，实现了部分 CSS 作用域的成果（scoping styles），各个组件的款式不会发生冲突。

如果不借助治理 CSS 的类库，把 CSS 和 JS 混合在一起，如果做的好，能够无效的做到组件隔离。如果做的不好，这个组件不仅会变得臃肿难以了解，你的 CSS 也会变得越来越难以保护。

八、编写无效的 HTML

很多人对 HTML 技术的关注度都是不够的，然而编写 HTML 和 CSS 依然是咱们前端工程师的必备工作。

React 是乏味的，Hooks 也是乏味的，但咱们最终关怀的是渲染 HTML 和使它看起来更敌对。

对于 HTML 元素来说，如果它是一个按钮，它应该是一个 <button>，而不是一个可点击的 div；如果它不进行表单提交，那么它应该是 type="button"；如果它应该基于文本大小自适应，它不应该有一个固定的宽度，等等。

对一些人来说，这是最根本的，但对于一部分人来说，状况并非如此。

咱们常常会看到相似的表单提交代码：

import React, {useState} from 'react';
const Form = () => {const [name, setName] = useState('');  
  const handleChange = e => {setName(e.target.value);
  }
  const handleSubmit = () => {// api call here} 
  return (
    <div>
      <input type="text" onChange={handleChange} value={name} />
      <button type="button" onClick={handleSubmit}>
        Submit
      </button>
    </div>
  )
}

这个示例所做的事是在 <input/> 上更新 name 值，并且在 <button/> 上绑定 click 事件，通过点击调用 handleSubmit 来提交数据。

这个性能对于通过应用按钮进行提交的用户是能够的，然而对于应用 Enter 键提交表单的用户来说就不行了。

对于 form 表单反对 Enter 提交，能够这么做，无需对 Enter 进行监听：

<form onsubmit="myFunction()">
  Enter name: <input type="text">
  <input type="submit">
</form>

在 React 中 应用 onSubmit 是等效的：

import React, {useState} from 'react';
const Form = () => {const [name, setName] = useState('');
  
  const handleChange = e => {setName(e.target.value);
  }
  
  const handleSubmit = e => {e.preventDefault();
    // api call here
  }
  
  return (<form onSubmit={handleSubmit}>
      <input type="text" onChange={handleChange} value={name} />
      <button type="submit">
        Submit
      </button>
    </form>
  )
}

当初，这个表单提交实用于任何触发场景，而不仅仅是一个只反对通过按钮点击的表单。

总结

1. 遵循繁多目标组件哲学，防止过于简单的多行组件，并尽可能地将组件合成。
2. 请记住，在父组件外部实现此操作总是比在组件自身外部实现更为洁净。
3. 当在 render 中返回 JSX 时，不要应用内联的 JavaScript 逻辑。
4. 组件外部定义的许多逻辑能够从组件中抽离，因为它的实现并不真正与组件相干。
5. 晚期将逻辑从组件中形象进去，能够让咱们领有更简洁的组件和易于重用的实用函数。
6. 如果不借助治理 CSS 的类库，把 CSS 和 JS 混合在一起，如果做的好，能够无效的做到组件隔离。如果做的不好，这个组件不仅会变得臃肿难以了解，你的 CSS 也会变得越来越难以保护。
7. React 是乏味的，Hooks 也是乏味的，但最终咱们关怀的是渲染 HTML 和使它看起来更敌对。

本文转载自公众号 [code 机密花园]
如有侵权分割删除