From 2bbf07b25e628dfac97a3b668c8a1a5fc2f3b5f8 Mon Sep 17 00:00:00 2001 From: Piotr Czajkowski Date: Thu, 5 Jan 2017 14:12:51 +0100 Subject: [PATCH] "Don't Mutate the Original Component" example and description mismatch (#8695) (cherry picked from commit df0d2a5106a225ae94ec978a99342443d57f83c2) --- docs/docs/higher-order-components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/higher-order-components.md b/docs/docs/higher-order-components.md index 5daf8e51b1..c27024c5fa 100644 --- a/docs/docs/higher-order-components.md +++ b/docs/docs/higher-order-components.md @@ -188,7 +188,7 @@ function logProps(InputComponent) { const EnhancedComponent = logProps(InputComponent); ``` -There are a few problems with this. One is that the input component cannot be reused separately from the enhanced component. More crucially, if you apply another HOC to `EnhancedComponent` that *also* mutates `shouldComponentUpdate`, the first HOC's functionality will be overridden! This HOC also won't work with function components, which do not have lifecycle methods. +There are a few problems with this. One is that the input component cannot be reused separately from the enhanced component. More crucially, if you apply another HOC to `EnhancedComponent` that *also* mutates `componentWillReceiveProps`, the first HOC's functionality will be overridden! This HOC also won't work with function components, which do not have lifecycle methods. Mutating HOCs are a leaky abstraction—the consumer must know how they are implemented in order to avoid conflicts with other HOCs.