{"componentChunkName":"component---src-templates-docs-js","path":"/docs/higher-order-components.html","result":{"data":{"markdownRemark":{"html":"

Um componente de ordem superior (HOC, do inglês Higher-Order Component) é uma técnica avançada do React para reutilizar a lógica de um componente. HOCs não são parte da API do React, per se. Eles são um padrão que surgiu da própria natureza de composição do React.

\n

Concretamente, um componente de ordem superior é uma função que recebe um componente e retorna um novo componente.

\n
const EnhancedComponent = higherOrderComponent(WrappedComponent);
\n

Enquanto um componente transforma props em UI, um componente de ordem superior transforma um componente em outro componente.

\n

HOCs são comuns em bibliotecas externas ao React, como o connect do Redux e o createFragmentContainer do Relay.

\n

Neste documento, nós vamos discutir porque componentes de ordem superior são úteis e como escrever o seu.

\n

Usar HOCs para características transversais.

\n
\n

Nota

\n

Anteriormente, nós recomendamos mixins como uma forma de lidar com características transversais. Desde então, percebemos que mixins criam mais problemas do que trazem valor. Leia mais sobre porque nós deixamos os mixins de lado e como você pode fazer a transição dos seus componentes existentes.

\n
\n

Componentes são a unidade primária de reutilização de código no React. Contudo, pode-se perceber que alguns padrões não se encaixam tão facilmente em componentes tradicionais.

\n

Por exemplo, digamos que você tem um componente CommentList que subscreve-se a uma fonte externa de dados para renderizar uma lista de comentários:

\n
class CommentList extends React.Component {\n  constructor(props) {\n    super(props);\n    this.handleChange = this.handleChange.bind(this);\n    this.state = {\n      // \"DataSource\" é uma fonte de dados global\n      comments: DataSource.getComments()\n    };\n  }\n\n  componentDidMount() {\n    // Subscreve-se às mudanças\n    DataSource.addChangeListener(this.handleChange);\n  }\n\n  componentWillUnmount() {\n    // Limpa o listener\n    DataSource.removeChangeListener(this.handleChange);\n  }\n\n  handleChange() {\n    // Atualiza o state do componente sempre que a fonte de dados muda\n    this.setState({\n      comments: DataSource.getComments()\n    });\n  }\n\n  render() {\n    return (\n      <div>\n        {this.state.comments.map((comment) => (\n          <Comment comment={comment} key={comment.id} />\n        ))}\n      </div>\n    );\n  }\n}
\n

Depois, você escreve um componente que se subscreve a um blog post, o qual segue um padrão similar:

\n
class BlogPost extends React.Component {\n  constructor(props) {\n    super(props);\n    this.handleChange = this.handleChange.bind(this);\n    this.state = {\n      blogPost: DataSource.getBlogPost(props.id)\n    };\n  }\n\n  componentDidMount() {\n    DataSource.addChangeListener(this.handleChange);\n  }\n\n  componentWillUnmount() {\n    DataSource.removeChangeListener(this.handleChange);\n  }\n\n  handleChange() {\n    this.setState({\n      blogPost: DataSource.getBlogPost(this.props.id)\n    });\n  }\n\n  render() {\n    return <TextBlock text={this.state.blogPost} />;\n  }\n}
\n

CommentList e BlogPost não são idênticos - eles chamam métodos diferentes de DataSource e renderizam saídas diferentes. Mas muito de suas implementações é igual:

\n\n

Você pode imaginar que em uma aplicação grande, esse mesmo padrão de subscrever-se a DataSource e chamar setState irá ocorrer várias vezes. Nós queremos uma abstração que permita-nos definir essa lógica em um único lugar e compartilhá-la com vários componentes. Isso é onde componentes de ordem superior se destacam.

\n

Nós podemos escrever uma função que cria componentes, como CommentList e BlogPost, que subscrevem-se a DataSource. A função irá aceitar como um dos seus argumentos um componente filho que recebe o dado assinado como uma prop. Vamos chamar a função de withSubscription:

\n
const CommentListWithSubscription = withSubscription(\n  CommentList,\n  (DataSource) => DataSource.getComments()\n);\n\nconst BlogPostWithSubscription = withSubscription(\n  BlogPost,\n  (DataSource, props) => DataSource.getBlogPost(props.id)\n);
\n

O primeiro parâmetro é um componente encapsulado. O segundo parâmetro acessa os dados que estamos interessados, dado um DataSource e as props atuais.

\n

Quando CommentListWithSubscription e BlogPostWithSubscription são renderizados, CommentList e BlogPost receberão uma prop data com os dados mais recentes obtidos de DataSource:

\n
// A função recebe um componente...\nfunction withSubscription(WrappedComponent, selectData) {\n  // ...e retorna outro componente...\n  return class extends React.Component {\n    constructor(props) {\n      super(props);\n      this.handleChange = this.handleChange.bind(this);\n      this.state = {\n        data: selectData(DataSource, props)\n      };\n    }\n\n    componentDidMount() {\n      // ... que lida com a subscrição...\n      DataSource.addChangeListener(this.handleChange);\n    }\n\n    componentWillUnmount() {\n      DataSource.removeChangeListener(this.handleChange);\n    }\n\n    handleChange() {\n      this.setState({\n        data: selectData(DataSource, this.props)\n      });\n    }\n\n    render() {\n      // ... e renderiza o componente encapsulado com os dados novos!\n      // Note que nós passamos diretamente qualquer prop adicional\n      return <WrappedComponent data={this.state.data} {...this.props} />;\n    }\n  };\n}
\n

Note que um HOC não modifica o componente de entrada, nem utiliza herança para copiar seu comportamento. Em vez disso, um HOC compõe o componente original ao envolvê-lo (wrapping) em um componente container. Um HOC é uma função pura sem efeitos colaterais.

\n

E é isso! O componente encapsulado recebe todas as props do container, junto de uma nova prop, data, o qual a utiliza para renderizar sua saída. O HOC não se preocupa com o como ou o porquê de seus dados serem usados, e o componente encapsulado não se preocupa de onde os dados vieram.

\n

Por withSubscription ser uma função normal, você pode adicionar quantos argumentos quiser. Por exemplo, você pode querer fazer o nome da prop data ser configurável, para continuar a isolar o HOC do componente encapsulado. Ou você pode aceitar um argumento que configura shouldComponentUpdate, ou um que configura a fonte de dados. Todos esses casos são possíveis porque o HOC tem controle total sobre como o componente é definido.

\n

Como componentes, o contrato entre withSubscription e o componente encapsulado é completamente baseado em props. Isso faz com que seja fácil trocar um HOC por outro, desde que eles providenciem as mesmas props para o componente encapsulado. Isso pode ser útil se você mudar de bibliotecas para obtenção de dados, por exemplo.

\n

Não alterar o componente original. Usar composição.

\n

Resista à tentação de modificar o prototype de um componente (ou alterá-lo de qualquer outra forma) dentro de um HOC.

\n
function logProps(InputComponent) {\n  InputComponent.prototype.componentDidUpdate = function(prevProps) {\n    console.log('Current props: ', this.props);\n    console.log('Previous props: ', prevProps);\n  };\n  // O fato de estarmos retornando a entrada original é uma dica de que ela sofreu mutação.\n  return InputComponent;\n}\n\n// EnhancedComponent criará logs sempre que uma prop for recebida\nconst EnhancedComponent = logProps(InputComponent);
\n

Existem alguns problemas nisso. Primeiro, o componente de entrada não pode ser reutilizado separadamente do componente melhorado. Mais crucialmente, se você aplicar outro HOC para EnhancedComponent que também altera componentDidUpdate, a funcionalidade do primeiro HOC será sobrescrita! Esse HOC também não funcionará com componentes funcionais, os quais não possuem métodos de ciclo de vida.

\n

Realizar mutações em HOCs podem causar “vazamentos” - o consumidor deve saber como eles são implementados para evitar conflitos com outros HOCs.

\n

Em vez de mutações, HOCs devem utilizar composição, encapsulando o componente de entrada em um componente container:

\n
function logProps(WrappedComponent) {\n  return class extends React.Component {\n    componentDidUpdate(prevProps) {\n      console.log('Current props: ', this.props);\n      console.log('Previous props: ', prevProps);\n    }\n    render() {\n      // Encapsula o componente de entrada em um container, sem alterá-lo. Excelente!\n      return <WrappedComponent {...this.props} />;\n    }\n  }\n}
\n

Esse HOC possui a mesma funcionalidade que a sua versão com mutação e evita o potencial de ocorrer conflitos. Ele funciona igualmente bem com componentes funcionais e controlados. E por ser uma função pura, pode ser combinado com outros HOCs, ou até com si mesmo.

\n

Você deve ter notado similaridades entre HOCs e um padrão chamado componentes container. Componentes container são parte de uma estratégia de separação de responsabilidade entre preocupações de alto nível e baixo nível. Containers gerenciam coisas como subscrições e state, e passam props para componentes que lidam com coisas como renderização da UI. HOCs utilizam containers como parte de sua implementação. Você pode pensar em HOCs como definições de componentes container com parâmetros.

\n

Convenção: Passar props não relacionadas para o componente encapsulado

\n

HOCs adicionam características a um componente. Eles não devem alterar drasticamente o seu contrato. É esperado que um componente retornado de um HOC tenha uma interface similar ao do componente encapsulado.

\n

HOCs devem passar props que não são relacionadas às suas preocupações específicas. A maioria dos HOCs possuem um método render que se parece com algo assim:

\n
render() {\n  // Filtra props extras que são específicas a esse HOC e não devem ser\n  // passadas para o componente encapsulado.\n  const { extraProp, ...passThroughProps } = this.props;\n\n  // Injeta props no componente encapsulado.\n  // Estes geralmente são valores do state ou métodos da instância.\n  const injectedProp = someStateOrInstanceMethod;\n\n  // Passa as props para o componente encapsulado.\n  return (\n    <WrappedComponent\n      injectedProp={injectedProp}\n      {...passThroughProps}\n    />\n  );\n}
\n

Essa convenção ajuda a garantir que HOCs são tão flexíveis e reutilizáves quanto possível.

\n

Convenção: Maximizando composabilidade

\n

Nem todos os HOCs são iguais. Às vezes eles aceitam apenas um único argumento, o componente encapsulado:

\n
const NavbarWithRouter = withRouter(Navbar);
\n

Normalmente, HOCs aceitam argumentos adicionais. Neste exemplo do Relay, um objeto de configuração é usado para especificar uma dependência de dados de um componente:

\n
const CommentWithRelay = Relay.createContainer(Comment, config);
\n

A assinatura mais comum para HOCs se parece com isso:

\n
// `connect` do React Redux\nconst ConnectedComment = connect(commentSelector, commentActions)(CommentList);
\n

O Que?! Se você quebrar isso em partes, é mais fácil de ver o que está acontecendo.

\n
// connect é uma função que retorna outra função\nconst enhance = connect(commentListSelector, commentListActions);\n// A função retornada é um HOC, que retorna um componente que está conectado\n// à store do Redux\nconst ConnectedComment = enhance(CommentList);
\n

Em outras palavras, connect é uma função de ordem superior que retorna um componente de ordem superior!

\n

Essa forma pode parecer confusa ou desnecessária, mas ela possui uma propriedade útil. HOCs com um único argumento, como o retornado pela função connect, possuem a assinatura Componente => Componente. Funções cujo tipo de saída é igual ao tipo da entrada são muito fáceis de se compor.

\n
// Em vez de fazer isso...\nconst EnhancedComponent = withRouter(connect(commentSelector)(WrappedComponent))\n\n// ... Você pode usar uma conveniência de composição de funções\n// compose(f, g, h) é o mesmo que (...args) => f(g(h(...args)))\nconst enhance = compose(\n  // Ambos são HOCs com um único argumento\n  withRouter,\n  connect(commentSelector)\n)\nconst EnhancedComponent = enhance(WrappedComponent)
\n

(Essa mesma propriedade também permite que connect e outros enhancer-style HOCs sejam usados como decoradores, uma proposta experimental do JavaScript.)

\n

A função de conveniência compose é disponibilizada por várias bibliotecas de terceiros, incluindo lodash (como o lodash.flowRight), Redux, e Ramda.

\n

Convenção: Envolver o nome de exibição para melhor depuração

\n

Os componentes container criados por HOCs aparecem no React Developer Tools como qualquer outro componente. Para facilitar a depuração, escolha um nome de exibição que comunique que o componente é o resultado de um HOC.

\n

A técnica mais comum é encapsular o nome de exibição do componente encapsulado. Então, se o seu componente de ordem superior se chama withSubscription, e o nome de exibição do componente encapsulado é CommentList, use o nome de exibição WithSubscription(CommentList):

\n
function withSubscription(WrappedComponent) {\n  class WithSubscription extends React.Component {/* ... */}\n  WithSubscription.displayName = `WithSubscription(${getDisplayName(WrappedComponent)})`;\n  return WithSubscription;\n}\n\nfunction getDisplayName(WrappedComponent) {\n  return WrappedComponent.displayName || WrappedComponent.name || 'Component';\n}
\n

Ressalvas

\n

Componentes de ordem superior vêm com algumas ressalvas que não são imediatamente óbvias se você for novo no React.

\n

Não usar HOCs dentro do método render

\n

O algoritmo de comparação do React (chamado Reconciliação) usa a identidade do componente para determinar se ele deve atualizar a sub-árvore existente ou jogá-la fora e montar uma nova. Se o componente que foi retornado do render é idêntico (===) ao componente do render anterior, o React atualizará a sub-árvore comparando-a recursivamente com uma nova. Se elas não forem iguais, a sub-árvore anterior será completamente desmontada.

\n

Normalmente, você não precisa se preocupar com isso. Mas isso é importante em HOCs porque não se pode aplicar um HOC em um componente dentro do método render de um componente:

\n
render() {\n  // Uma nova versão de EnhancedComponent é criada toda vez que render for chamado\n  // EnhancedComponent1 !== EnhancedComponent2\n  const EnhancedComponent = enhance(MyComponent);\n  // Isso faz com que a sub-árvore seja completamente\n  // desmontada/remontada todas as vezes!\n  return <EnhancedComponent />;\n}
\n

O problema aqui não é só na performance - remontar um componente causa a perda de todo o seu state e todos os seus filhos.

\n

Em vez disso, aplique HOCs fora da definição do componente para que o componente resultante seja criado apenas uma vez. Então, sua identidade será consistente pelas renderizações. De qualquer forma, isso geralmente é o que você quer.

\n

Nesses casos raros em que é preciso aplicar um HOC dinamicamente, isso também pode ser feito dentro dos métodos de ciclo de vida do componente, ou no seu construtor.

\n

Métodos estáticos devem ser propagados

\n

As vezes é útil definir um método estático em um componente do React. Por exemplo, containers do Relay expõem um método estático getFragment para facilitar a composição de fragmentos do GraphQL.

\n

Mas, quando se aplica um HOC a um componente, o componente original é encapsulado com um componente container. Isso significa que o novo componente não possui nenhum dos métodos estáticos do componente original.

\n
// Defina um método estático\nWrappedComponent.staticMethod = function() {/*...*/}\n// Agora aplique um HOC\nconst EnhancedComponent = enhance(WrappedComponent);\n\n// O EnhancedComponent não possui métodos estáticos\ntypeof EnhancedComponent.staticMethod === 'undefined' // true
\n

Para resolver isso, você pode copiar os métodos no container antes de retorná-lo:

\n
function enhance(WrappedComponent) {\n  class Enhance extends React.Component {/*...*/}\n  // Deve-se saber exatamente qual método copiar :(\n  Enhance.staticMethod = WrappedComponent.staticMethod;\n  return Enhance;\n}
\n

Porém, isso requer que você saiba exatamente quais métodos precisam ser copiados. A biblioteca hoist-non-react-statics pode ser usada para copiar automaticamente todos os métodos estáticos que não são do React:

\n
import hoistNonReactStatic from 'hoist-non-react-statics';\nfunction enhance(WrappedComponent) {\n  class Enhance extends React.Component {/*...*/}\n  hoistNonReactStatic(Enhance, WrappedComponent);\n  return Enhance;\n}
\n

Outra solução possível é exportar o método estático do próprio componente, separadamente.

\n
// Em vez de...\nMyComponent.someFunction = someFunction;\nexport default MyComponent;\n\n// ... exporte o método separadamente...\nexport { someFunction };\n\n// ... e no módulo que está consumindo, importe ambos\nimport MyComponent, { someFunction } from './MyComponent.js';
\n

Refs não são passadas diretamente

\n

Enquanto a convenção para componentes de ordem superior é passar diretamente todas as props para o componente encapsulado, isso não funciona para refs. Isso acontece porque ref não é exatamente uma prop - tal como key, ela é tratada de maneira especial pelo React. Se uma ref for adicionado a um elemento cujo componente é o resultado de um HOC, a ref referenciará à instância mais externa do componente container, não ao componente encapsulado.

\n

A solução para esse problema é usar a API React.forwardRef (introduzida com o React 16.3). Saiba mais sobre ela na seção de encaminhamento de refs.

","frontmatter":{"title":"Componentes de Ordem Superior","next":null,"prev":null},"fields":{"path":"content/docs/higher-order-components.md","slug":"docs/higher-order-components.html"}}},"pageContext":{"slug":"docs/higher-order-components.html"}},"staticQueryHashes":[]}