prefácio
O React é uma estrutura de front-end muito flexível porque não força os desenvolvedores a usar uma API interna ou uma biblioteca de terceiros para concluir uma determinada função. Por exemplo, o React não obriga você a usar Class Component ou Functional Component para desenvolver um determinado componente, que é completamente determinado pelo desenvolvedor de acordo com seu próprio cenário. Para o uso de bibliotecas de terceiros, o React não possui requisitos. Por exemplo, para gerenciamento de estado, o ecossistema React possui várias bibliotecas muito populares que podem ser usadas, como Redux , Mobx , XState e Jotai , etc. É precisamente por causa da flexibilidade do React que o site oficial do React diz apenas que é uma biblioteca de interface do usuário em vez de um framework de interface do usuário.
Há prós e contras para uma grande flexibilidade. A vantagem é que a ecologia da comunidade é próspera , e os desenvolvedores podem desenvolver uma biblioteca que atenda a um cenário especial para usar com o React de acordo com suas necessidades especiais. A desvantagem também é óbvia, ou seja, se houver muitas opções para implementar a mesma função, é muito hostil para desenvolvedores juniores . Porque eles não sabem qual API nativa ou biblioteca de terceiros eles precisam usar para concluir o desenvolvimento de uma determinada função. Se você escolher o errado, pode fazer com que o aplicativo desenvolvido tenha problemas de desempenho ou reduza a eficiência do desenvolvimento. De fato, não apenas o uso de bibliotecas de terceiros, mas também o uso da API React nativa, os componentes escritos por diferentes programadores são muito diferentes e a qualidade do código também é desigual. Por esses motivos, vou escrever uma série de artigos sobre as melhores práticas do React para apresentar alguns dos problemas que são frequentemente encontrados no desenvolvimento do React e como usar as melhores práticas para resolvê-los. Conhecer essas práticas recomendadas não apenas o ajudará a tomar melhores decisões técnicas durante o desenvolvimento, mas também lhe dará uma vantagem durante as entrevistas de front-end.
Este artigo, o primeiro de uma série, apresentará 5 práticas recomendadas.
Evite componentes grandes, aprenda a dividir componentes
Como o React não tem limite no tamanho dos componentes, podemos escrever alguns componentes relativamente grandes no desenvolvimento diário, como o seguinte exemplo simplificado:
O componente App acima é um componente grande que precisa ser dividido na minha opinião, pois contém todo o conteúdo dos dois subcomponentes Nav e Content , o que tornará nossos componentes difíceis de testar e manter . Nossa prática recomendada para componentes grandes é dividi-los por responsabilidades, e o componente pai se preocupa apenas com o layout dos componentes filhos . Com base nessa ideia, os componentes grandes acima podem ser divididos em dois subcomponentes Nav e Content e um componente grande App . O componente grande cria uma div wrapper para cada subcomponente para definir seu layout . Em outras palavras: o componente grande não precisa se preocupar com o conteúdo dos subcomponentes, ele só precisa definir como os subcomponentes estão dispostos dentro dele e passar as informações contextuais necessárias . Então nosso código fica:
Há muitas vantagens em escrever desta forma: em primeiro lugar, grandes componentes e subcomponentes podem ser testados e desenvolvidos separadamente, e mudanças e atualizações dentro de subcomponentes não afetarão o código de grandes componentes.
Se nossos componentes forem muito grandes para copiar e colar muito código durante a refatoração, podemos usar o plugin glean para VSCode para automatizar essa operação. Glean pode nos ajudar a extrair rapidamente um pedaço de código JSX em um único componente. A figura a seguir mostra como usar o glean para reconstruir o componente App: Após clicar em Extract Component to File e preencher o nome do arquivo na figura acima, o conteúdo é extraído para um componente separado.
避免出现嵌套组件
我在日常工作中会看到一些程序员在一个组件里面定义另外一个组件:
上面的代码写起来的确十分方便，因为Child组件是定义在Parent组件里面的，所以它可以直接使用Parent组件里面定义的handleClick函数而不用定义和传递props。不过这种写法却有可能隐藏着严重的性能问题：Child组件会在每次Parent组件重新渲染的时候被重定义，这也就意味着旧的Child组件定义会被销毁，新的组件会被创建。对于嵌套组件我们的最佳实践是：一般不定义嵌套组件，所有的组件都要提出父组件单独定义。基于这个最佳实践，上面的代码可以被改成：
重构完后，Child组件被单独拎出来定义，通过onClick的props接受来自父组件的handleClick函数，这不但可以避免组件被重新定义的性能问题，还可以让我们组件的职责更加分明和便于测试。不过这里把Child组件和Parent组件的定义都放在同一个文件其实也是一个反模式的做法，我们马上就会说到。
每个文件只定义一个组件
在上面的例子中Child和Parent组件都被定义在了同一个文件中，这种做法在Child组件只需要被Parent组件使用的时候是没有问题的。可是如果Child组件也需要被export出来被其它组件使用的话，代码就会开始变得混乱了，例如可能会有下面这种import语句出现:
因此我们这里更好的做法应该是：一个文件里面只定义一个组件。在上面的例子中就需要将Parent和Child两个组件拆分成两个文件：Parent.jsx和Child.jsx。这个最佳实践是可以用eslint-plugin-react里面的no-multi-comp规则来自动约束的。
其实在我的团队里面，我不但要求不同的组件定义到不同的文件里面，我还要求每一个组件都要有一个单独的文件夹，组件的定义放在它对应文件夹的index.jsx文件里面。我这样要求组员的理由是：一个React组件往往有很多配套的文件，例如单元测试，CSS Module定义或者StoryBook的Story等等。这些文件都是和组件强相关的，我们把它们和组件文件放在一起的话有利于后面我们对代码的重构。举个例子下面是我们项目代码里面Navbar组件的目录结构：
试想一下哪天我们项目不需要这个组件了，我们只需删除Navbar这个文件夹即可，而无需担心还有和这个组件关联的逻辑散落在项目的其它地方。
使用useMemo来避免组件里面的重复计算
假如我们的组件里面需要进行一些比较耗费CPU的计算:
上面这个组件调用了expensiveCalculation函数，这个函数会在组件每次渲染的时候被调用。这里面有一个问题就是无论count字段是否改变，这个大计算量的函数都会被调用，这其实会造成一定程度的性能消耗。对于这个场景我们的优化思路是使用useMemo来避免expensiveCalculation函数的重复调用，具体做法是:
useMemo这个hook可以保证只有在count这个状态变化的时候expensiveCalculation才会被调用。如果你对useMemo不够熟悉的话可以参考一下我写的超详细React Hook实践指南。
避免使用无用的div
我们知道React是不允许我们在组件的render里面返回一个dom数组的。因为这个原因很多开发者在写组件的时候都喜欢在最外层包一个毫无意义的div:
上面的写法会导致最终渲染在页面的无用div越来越多，这不但会影响到我们页面的accessibility，还可能会让无用的div干扰我们对页面的debug。这里我们的最佳实践是使用React.Fragment来替代这个无用的div:
和空div不同，React的Fragment元素不会生成一个新的div，也就避免了上面说到的这些问题。每次都写React.Fragment其实不够方便，因此React为你提供了更加方便的写法:
总结
上面为大家总结了5个我们在日常开发React应用时可以使用到的最佳实践，后面我会不断更新这个系列的内容，为大家带来更多的React最佳实践。
个人技术动态
创作不易，如果你从这篇文章中学到东西，请给我点一下赞或者关注，你的支持是我继续创作的最大动力！
Ao mesmo tempo, dê as boas-vindas às cebolas que prestam atenção ao ataque à conta pública para aprender e crescer juntos