recompose - npm Package Compare versions

Comparing version 0.5.0 to 0.5.1

isReferentiallyTransparentFunctionComponent.js

		@@ -5,3 +5,3 @@ 'use strict';
		var isReferentiallyTransparentFunctionComponent = function isReferentiallyTransparentFunctionComponent(Component) {
		return Component && typeof Component !== 'string' && !(Component.prototype && Component.prototype.render) && !Component.contextTypes;
		return Component && typeof Component !== 'string' && !(Component.prototype && Component.prototype.render) && !Component.defaultProps && !Component.contextTypes;
		};
		@@ -8,0 +8,0 @@

package.json

		{
		"name": "recompose",
		"version": "0.5.0",
		"version": "0.5.1",
		"description": "A microcomponentization toolkit for React",
		@@ -5,0 +5,0 @@ "main": "index.js",

README.md

		@@ -108,9 +108,9 @@ Recompose

		If function composition doesn't scare you, then yes, I think so. I believe using higher-order component helpers leads to smaller, more focused components, and provides a better programming model than using classes for operations -- like `mapProps()` or `shouldUpdate()` -- that aren't inherently class-y.
		If function composition doesn't scare you, then yes, I think so. I believe using higher-order component helpers leads to smaller, more focused components, and provides a better programming model than using classes for operations—like `mapProps()` or `shouldUpdate()`—that aren't inherently class-y.

		That being said, any abstraction over an existing API is going to come with trade-offs. There is a performance overhead when introducing a new component to the tree. I suspect this cost is negligible compared to the gains achieved by blocking subtrees from re-rendering using `shouldComponentUpdate()` — which Recompose makes easy with its `shouldUpdate()` and `onlyUpdateForKeys()` helpers. In the future, I'll work on some benchmarks so we know what we're dealing with.
		That being said, any abstraction over an existing API is going to come with trade-offs. There is a performance overhead when introducing a new component to the tree. I suspect this cost is negligible compared to the gains achieved by blocking subtrees from re-rendering using `shouldComponentUpdate()`—which Recompose makes easy with its `shouldUpdate()` and `onlyUpdateForKeys()` helpers. In the future, I'll work on some benchmarks so we know what we're dealing with.

		However, many of Recompose's higher-order component helpers are implemented using stateless function components rather than class components. Eventually, React will include optimizations for stateless components. Until then, we can do our own optimizations by taking advantage of referential transparency. In other words, creating an element from a stateless function is effectively* the same as calling the function and returning its output.

		* Stateless function components are not referentially transparent if they access context; we detect that by checking for the existence of `contextTypes`.
		\* Stateless function components are not referentially transparent if they access context or use default props; we detect that by checking for the existence of `contextTypes` and `defaultProps`.

		@@ -117,0 +117,0 @@ To accomplish this, Recompose uses a special version of `createElement()` that returns the output of stateless functions instead of creating a new element. For class components, it uses the built-in `React.createElement()`.

recompose - npm Package Compare versions

Improved metrics