New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stateless functional components and shouldComponentUpdate #5677

Closed
slorber opened this Issue Dec 16, 2015 · 36 comments

Comments

Projects
None yet
@slorber
Contributor

slorber commented Dec 16, 2015

This is probably a question / documentation issue.

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);

In some places of the doc we can read:

https://facebook.github.io/react/docs/reusable-components.html

In an ideal world, most of your components would be stateless functions because these stateless components can follow a faster code path within the React core. This is the recommended pattern, when possible.

https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html

This pattern is designed to encourage the creation of these simple components that should comprise large portions of your apps. In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations.

What I find unclear is these explainations is how React optimize the rendering when using stateless functional components. The good sense would be that React uses something similar to shallowEqual to know if it has to call the function or not, but as React does not enforce strict immutability yet (I mean the PureRenderMixin is actually an option, not the default), I wonder how these functional components behave.

I think this should be better documented if any memoization technique is used when rendering these functional components, because it's not so obvious to me if my app will perform almost the same (or better) if I choose to replace all my components using PureRenderMixin and no state/lifecycle methods by functional components as I don't have much insights of the internal working of the optimizations done.

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Dec 16, 2015

Contributor

For complex components, defining shouldComponentUpdate (eg. pure render) will generally exceed the performance benefits of stateless components. The sentences in the docs are hinting at some future optimizations that we have planned, whereby we won't allocate an internal instance for stateless functional components (we will just call the function). We also might not keep holding the props, etc. Tiny optimizations. We don't talk about the details in the docs because the optimizations aren't actually implemented yet (stateless components open the doors to these optimizations).

Contributor

jimfb commented Dec 16, 2015

For complex components, defining shouldComponentUpdate (eg. pure render) will generally exceed the performance benefits of stateless components. The sentences in the docs are hinting at some future optimizations that we have planned, whereby we won't allocate an internal instance for stateless functional components (we will just call the function). We also might not keep holding the props, etc. Tiny optimizations. We don't talk about the details in the docs because the optimizations aren't actually implemented yet (stateless components open the doors to these optimizations).

@slorber

This comment has been minimized.

Show comment
Hide comment
@slorber

slorber Dec 17, 2015

Contributor

Thanks

So what I understand is that currently functional components do not memoize their execution based on shallowCompare of props right? Couldn't it be implemented easily?

Contributor

slorber commented Dec 17, 2015

Thanks

So what I understand is that currently functional components do not memoize their execution based on shallowCompare of props right? Couldn't it be implemented easily?

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Dec 17, 2015

Contributor

Correct. Such memoization would break any application that was not using immutable data, because the "optimization" would be making an assumption that the root prop reference changes when the data changes. Imagine that the prop is an array, pushing to the array would not show up in a shallowCompare, which is why that optimization is not valid by default.

Contributor

jimfb commented Dec 17, 2015

Correct. Such memoization would break any application that was not using immutable data, because the "optimization" would be making an assumption that the root prop reference changes when the data changes. Imagine that the prop is an array, pushing to the array would not show up in a shallowCompare, which is why that optimization is not valid by default.

@slorber

This comment has been minimized.

Show comment
Hide comment
@slorber

slorber Dec 17, 2015

Contributor

So how can I use that memoization with a functional component? Will I be able to do so in the future?

I guess I could wrap it in an HOC but this then probably defeats the purpose of using functional components for the coming little optimizations that can be done

Contributor

slorber commented Dec 17, 2015

So how can I use that memoization with a functional component? Will I be able to do so in the future?

I guess I could wrap it in an HOC but this then probably defeats the purpose of using functional components for the coming little optimizations that can be done

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Dec 17, 2015

Contributor

There are discussions about having a pureRender flag that you could set on the function, or allowing it to participate in the shouldUpdate lifecycle, but that's currently not implemented. At the moment, stateless functions can not be pure-render.

It is worth keeping in mind that sometimes people abuse/overuse pure-render; it can sometimes be as or more expensive than running the render again, because you're iterating over the array of props and potentially doing things like string compares, which is just extra work for components that ultimately return true and then proceed to rerender anyway. PureRender / shouldComponentUpdate really is considered an escape hatch for performance and is not necessarily something that should be blindly applied to every component.

Contributor

jimfb commented Dec 17, 2015

There are discussions about having a pureRender flag that you could set on the function, or allowing it to participate in the shouldUpdate lifecycle, but that's currently not implemented. At the moment, stateless functions can not be pure-render.

It is worth keeping in mind that sometimes people abuse/overuse pure-render; it can sometimes be as or more expensive than running the render again, because you're iterating over the array of props and potentially doing things like string compares, which is just extra work for components that ultimately return true and then proceed to rerender anyway. PureRender / shouldComponentUpdate really is considered an escape hatch for performance and is not necessarily something that should be blindly applied to every component.

@slorber

This comment has been minimized.

Show comment
Hide comment
@slorber

slorber Dec 17, 2015

Contributor

I would be happy to have that flag.

yes I understand that however in most cases where we start to compare primitive values there's generally a parent that may already have memoized the rendering. It's often the data is coming from an API or is stored in objects so your primitives are probably in an immutable object at first before being dispatched to deeper components, thus giving the dispatcher parent to block rendering.

I think in ELM or Om this is applied by default to all the tree and works pretty well.

Is it that bad to compare strings vs comparing object identities? I guess strings hashes are compared first no?

Contributor

slorber commented Dec 17, 2015

I would be happy to have that flag.

yes I understand that however in most cases where we start to compare primitive values there's generally a parent that may already have memoized the rendering. It's often the data is coming from an API or is stored in objects so your primitives are probably in an immutable object at first before being dispatched to deeper components, thus giving the dispatcher parent to block rendering.

I think in ELM or Om this is applied by default to all the tree and works pretty well.

Is it that bad to compare strings vs comparing object identities? I guess strings hashes are compared first no?

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Dec 17, 2015

Contributor

Elm and Om are both far more functional/immutable than general javascript, which is probably why it makes more sense there. We are supporting standard javascript as a target language, and javascript is a language where mutability is common.

My perf benchmarks have found string compares to sometimes be quite slow (just doing string-compares of the prop-names with pre-defined values that we need to handle specially, and that isn't even arbitrarily long data compares). Hash comparison can only detect miss-matches, but can not guarantee that two strings are equal (due to collisions), so to prove equality you still need to walk the whole string, but your assumption is that the two strings are equal in the common case, otherwise why would you be using pure-render (ie. with hashing, you still need to walk the whole string in the supposed common case). String pooling does a better job than hashing, but it starts to get complicated.

Anyway, we digress. The simple answer is: no, we don't do pure render by default, but we may provide a way for you to opt-in in the future.

Contributor

jimfb commented Dec 17, 2015

Elm and Om are both far more functional/immutable than general javascript, which is probably why it makes more sense there. We are supporting standard javascript as a target language, and javascript is a language where mutability is common.

My perf benchmarks have found string compares to sometimes be quite slow (just doing string-compares of the prop-names with pre-defined values that we need to handle specially, and that isn't even arbitrarily long data compares). Hash comparison can only detect miss-matches, but can not guarantee that two strings are equal (due to collisions), so to prove equality you still need to walk the whole string, but your assumption is that the two strings are equal in the common case, otherwise why would you be using pure-render (ie. with hashing, you still need to walk the whole string in the supposed common case). String pooling does a better job than hashing, but it starts to get complicated.

Anyway, we digress. The simple answer is: no, we don't do pure render by default, but we may provide a way for you to opt-in in the future.

@slorber

This comment has been minimized.

Show comment
Hide comment
@slorber

slorber Dec 17, 2015

Contributor

so this is fine :)

I don't know so much about the javascript's inner working but coming from Java world we have string pooling built-in so I may assume wrong things about js :)

Contributor

slorber commented Dec 17, 2015

so this is fine :)

I don't know so much about the javascript's inner working but coming from Java world we have string pooling built-in so I may assume wrong things about js :)

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Dec 17, 2015

Contributor

I also come from a Java background. Java's pooling works pretty well, but you still can't depend on str1 == str2 in Java, for exactly the reason that pooling is not guaranteed by the JVM because "it starts to get complicated".

Contributor

jimfb commented Dec 17, 2015

I also come from a Java background. Java's pooling works pretty well, but you still can't depend on str1 == str2 in Java, for exactly the reason that pooling is not guaranteed by the JVM because "it starts to get complicated".

@tjconcept

This comment has been minimized.

Show comment
Hide comment
@tjconcept

tjconcept Jan 8, 2016

Interesting read. I assumed functional components would be "pure render" by default when seeing the syntax and reading the blog post about 0.14.

tjconcept commented Jan 8, 2016

Interesting read. I assumed functional components would be "pure render" by default when seeing the syntax and reading the blog post about 0.14.

@jimfb

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Jan 8, 2016

Contributor

I'm going to close this out, since it was mostly a discussion thread and there is nothing actionable here.

Contributor

jimfb commented Jan 8, 2016

I'm going to close this out, since it was mostly a discussion thread and there is nothing actionable here.

@jimfb jimfb closed this Jan 8, 2016

@giltig

This comment has been minimized.

Show comment
Hide comment
@giltig

giltig Jan 18, 2016

Hi, the action that I think should be here is memoization by default of stateless functions of React.
Here is an example of doing it manually - notice the diffs in the console.log...:
https://jsfiddle.net/giltig/a6ehwonv/28/

giltig commented Jan 18, 2016

Hi, the action that I think should be here is memoization by default of stateless functions of React.
Here is an example of doing it manually - notice the diffs in the console.log...:
https://jsfiddle.net/giltig/a6ehwonv/28/

@idrm

This comment has been minimized.

Show comment
Hide comment
@idrm

idrm Jun 21, 2016

@giltig, Your memoization function will not work as intended when there are multiple instances of the same component with different properties.

idrm commented Jun 21, 2016

@giltig, Your memoization function will not work as intended when there are multiple instances of the same component with different properties.

@jooj123

This comment has been minimized.

Show comment
Hide comment
@jooj123

jooj123 Aug 20, 2016

Is there any sort of rule of thumb for react being quicker for a component to render with many stateless functions or many classes with shouldComponentUpdate shallow equals.
Or is it something that needs to be profiled for every use case?

In my case there is many small components that are very small and are constantly mounted and unmounted.

I assume there will massive perf savings in mounting / unmounting for stateless because there is no lifecycle ?

jooj123 commented Aug 20, 2016

Is there any sort of rule of thumb for react being quicker for a component to render with many stateless functions or many classes with shouldComponentUpdate shallow equals.
Or is it something that needs to be profiled for every use case?

In my case there is many small components that are very small and are constantly mounted and unmounted.

I assume there will massive perf savings in mounting / unmounting for stateless because there is no lifecycle ?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 20, 2016

Member

There are currently no special optimizations done for functions, although we might add such optimizations in the future. But for now, they perform exactly as classes.

Member

gaearon commented Aug 20, 2016

There are currently no special optimizations done for functions, although we might add such optimizations in the future. But for now, they perform exactly as classes.

@jooj123

This comment has been minimized.

Show comment
Hide comment
@jooj123

jooj123 Aug 20, 2016

fair enough - after running through parts of the react source, i can see that stateless functions still mount like regular classes

jooj123 commented Aug 20, 2016

fair enough - after running through parts of the react source, i can see that stateless functions still mount like regular classes

@giltig

This comment has been minimized.

Show comment
Hide comment
@giltig

giltig Aug 21, 2016

@idrm Hi, but that's all the point. Memoization works when you give the component the same props which is exactly what we want, so it will only trigger render for components who receives different props thus getting pure rendering for stateless components as well (without shouldComponentUpdate)

giltig commented Aug 21, 2016

@idrm Hi, but that's all the point. Memoization works when you give the component the same props which is exactly what we want, so it will only trigger render for components who receives different props thus getting pure rendering for stateless components as well (without shouldComponentUpdate)

@shishirarora3

This comment has been minimized.

Show comment
Hide comment
@shishirarora3

shishirarora3 Aug 21, 2016

So should we memoize or is it already done in react code?

On Sun, 21 Aug 2016 19:53 giltig, notifications@github.com wrote:

@idrm https://github.com/idrm Hi, but that's all the point. Memoization
works when you give the component the same props which is exactly what we
want, so it will only trigger render for components who receives different
props thus getting pure rendering for stateless components as well (without
shouldComponentUpdate)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5677 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIKvJuUgyQZo23Qyx13sCem88jI8yC3vks5qiF9rgaJpZM4G2hkT
.

shishirarora3 commented Aug 21, 2016

So should we memoize or is it already done in react code?

On Sun, 21 Aug 2016 19:53 giltig, notifications@github.com wrote:

@idrm https://github.com/idrm Hi, but that's all the point. Memoization
works when you give the component the same props which is exactly what we
want, so it will only trigger render for components who receives different
props thus getting pure rendering for stateless components as well (without
shouldComponentUpdate)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5677 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIKvJuUgyQZo23Qyx13sCem88jI8yC3vks5qiF9rgaJpZM4G2hkT
.

@giltig

This comment has been minimized.

Show comment
Hide comment
@giltig

giltig Aug 21, 2016

There is a library
https://www.npmjs.com/package/memoization
You can use and just memoize all your stateless components (in export for example)

giltig commented Aug 21, 2016

There is a library
https://www.npmjs.com/package/memoization
You can use and just memoize all your stateless components (in export for example)

@idrm

This comment has been minimized.

Show comment
Hide comment
@idrm

idrm Aug 27, 2016

@giltig, what I'm saying is that your memoization function (purify) is, essentially, a component instance cache with a bucket size of 1 per "purified" component. I don't see how a memoize approach can become a substitute for shouldComponentUpdate the way React currently works.

idrm commented Aug 27, 2016

@giltig, what I'm saying is that your memoization function (purify) is, essentially, a component instance cache with a bucket size of 1 per "purified" component. I don't see how a memoize approach can become a substitute for shouldComponentUpdate the way React currently works.

andersmurphy added a commit to andersmurphy/js-quiz-client that referenced this issue Dec 25, 2016

refactors score component
Refactors score component to define it as a function that take props.
As this makes for simpler and more understandable components (they also
prevent components from having state).

For testing this required installing enzyme a test library that
simplifies shallow render testing (built on: reacts inbuilt shallow
rendering).

Note 1 - currently components as functions do not support shallow
compare that PureComponents do, unfortunately this negates one of the
many benefits of using immutable and persistent data structures.
Hopefully, this feature will be added in future.
facebook/react#5677

Note 2 - components that are defined as functions that take props
do not currently support refs.

commands:
npm i --save-dev enzyme
@Recmo

This comment has been minimized.

Show comment
Hide comment
@Recmo

Recmo Feb 16, 2017

Here's a simple work-around:

function pure(func) {
  class PureComponentWrap extends React.PureComponent {
    render() {
      return func(this.props, this.context)
    }
  }
  return PureComponentWrap
}
const MyComponent = pure(({msg}, {style}) =>
  <span style={style}>{msg}</span>
)

MyComponent.contextTypes = {
  style: React.PropTypes.string
}

Unlike pure and memoize from recompose and memoization, this turns the stateless functional component in a PureComponent:

Recmo commented Feb 16, 2017

Here's a simple work-around:

function pure(func) {
  class PureComponentWrap extends React.PureComponent {
    render() {
      return func(this.props, this.context)
    }
  }
  return PureComponentWrap
}
const MyComponent = pure(({msg}, {style}) =>
  <span style={style}>{msg}</span>
)

MyComponent.contextTypes = {
  style: React.PropTypes.string
}

Unlike pure and memoize from recompose and memoization, this turns the stateless functional component in a PureComponent:

@jwcone

This comment has been minimized.

Show comment
Hide comment
@jwcone

jwcone Feb 19, 2017

@Recmo

I'm new to React, so I welcome any correction/explanation, but I think you'd want to include a defaultProps assignment in your pure() function:

PureComponentWrap.defaultProps = func.defaultProps

Also, as a tangent, is this basically the HOC wrap approach that slorber mentioned, earlier?

jwcone commented Feb 19, 2017

@Recmo

I'm new to React, so I welcome any correction/explanation, but I think you'd want to include a defaultProps assignment in your pure() function:

PureComponentWrap.defaultProps = func.defaultProps

Also, as a tangent, is this basically the HOC wrap approach that slorber mentioned, earlier?

@clayne11

This comment has been minimized.

Show comment
Hide comment
@clayne11

clayne11 Mar 15, 2017

You shouldn't use defaultProps for functional components. You should use the language and use default parameters in the function.

clayne11 commented Mar 15, 2017

You shouldn't use defaultProps for functional components. You should use the language and use default parameters in the function.

@Klaasvaak

This comment has been minimized.

Show comment
Hide comment
@Klaasvaak

Klaasvaak Mar 23, 2017

Should this do the trick?

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);
Aquarium.prototype.isPureReactComponent = true;

Klaasvaak commented Mar 23, 2017

Should this do the trick?

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);
Aquarium.prototype.isPureReactComponent = true;
@mir3z

This comment has been minimized.

Show comment
Hide comment
@mir3z

mir3z Mar 24, 2017

To sum up the discussion... The current state is that functional components are always re-rendered even if props are unchanged, right?

How is that different from non-functional components? Correct me if I'm wrong but my understanding is that React does not compare props or state itself unless you provide shouldComponentUpdate. On the other hand it compares virtual dom representation to find out what actually have changed.

mir3z commented Mar 24, 2017

To sum up the discussion... The current state is that functional components are always re-rendered even if props are unchanged, right?

How is that different from non-functional components? Correct me if I'm wrong but my understanding is that React does not compare props or state itself unless you provide shouldComponentUpdate. On the other hand it compares virtual dom representation to find out what actually have changed.

@jooj123

This comment has been minimized.

Show comment
Hide comment
@jooj123

jooj123 Mar 26, 2017

@mir3z

To sum up the discussion... The current state is that functional components are always re-rendered even if props are unchanged, right?

Correct.

How is that different from non-functional components?

You can provide a shouldComponentUpdate check with these and prevent the diffing algorithm from being run - potentially adding some performance gains.
Both functional and non-functional use the same dom diffing process from my understanding

jooj123 commented Mar 26, 2017

@mir3z

To sum up the discussion... The current state is that functional components are always re-rendered even if props are unchanged, right?

Correct.

How is that different from non-functional components?

You can provide a shouldComponentUpdate check with these and prevent the diffing algorithm from being run - potentially adding some performance gains.
Both functional and non-functional use the same dom diffing process from my understanding

@davidworkman9

This comment has been minimized.

Show comment
Hide comment
@davidworkman9

davidworkman9 Mar 29, 2017

@Klaasvaak

Should this do the trick?

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);
Aquarium.prototype.isPureReactComponent = true;

Looks like it doesn't. https://jsfiddle.net/a6ehwonv/92/

davidworkman9 commented Mar 29, 2017

@Klaasvaak

Should this do the trick?

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);
Aquarium.prototype.isPureReactComponent = true;

Looks like it doesn't. https://jsfiddle.net/a6ehwonv/92/

@Klaasvaak

This comment has been minimized.

Show comment
Hide comment
@Klaasvaak

Klaasvaak commented Mar 30, 2017

@davidworkman9 was looking at this code here: https://github.com/facebook/react/blob/v15.4.2/src/renderers/shared/stack/reconciler/ReactCompositeComponent.js#L70 and thought that it might work. But I guess it doesn't

@msuperina

This comment has been minimized.

Show comment
Hide comment
@msuperina

msuperina Apr 10, 2017

I started working at this small library that may be helpful in such situations.
https://github.com/msuperina/react-cache
It is definitely just a start as there may be many more optimizations to do.

msuperina commented Apr 10, 2017

I started working at this small library that may be helpful in such situations.
https://github.com/msuperina/react-cache
It is definitely just a start as there may be many more optimizations to do.

@Huxpro

This comment has been minimized.

Show comment
Hide comment
@Huxpro

Huxpro Jun 21, 2017

It's surprising that functional component not PureComponent by default...

Huxpro commented Jun 21, 2017

It's surprising that functional component not PureComponent by default...

@a8568730

This comment has been minimized.

Show comment
Hide comment
@a8568730

a8568730 Jul 21, 2017

I wrap my functional components with Recompose.pure.

const ExpensiveChild = ({children}) => {
  return(
  <p>Hi {children}</p>
)}

const PureChild = Recompose.pure(ExpensiveChild)

Codepen

a8568730 commented Jul 21, 2017

I wrap my functional components with Recompose.pure.

const ExpensiveChild = ({children}) => {
  return(
  <p>Hi {children}</p>
)}

const PureChild = Recompose.pure(ExpensiveChild)

Codepen

@felquis

This comment has been minimized.

Show comment
Hide comment
@felquis

felquis Jul 31, 2017

I improved @davidworkman9's example #5677 (comment) ... here -> https://jsfiddle.net/tynt7te9/ and updated to 15.6.1

I realized the best thing to do is to use:

class PureComponent extends React.PureComponent {
  render () {
    console.count('PureComponent')
    return <div>React.PureComponent: {this.props.render}</div>
  }
 
  shouldComponentUpdate: false
}

https://jsfiddle.net/tynt7te9/1/ pretty cool

felquis commented Jul 31, 2017

I improved @davidworkman9's example #5677 (comment) ... here -> https://jsfiddle.net/tynt7te9/ and updated to 15.6.1

I realized the best thing to do is to use:

class PureComponent extends React.PureComponent {
  render () {
    console.count('PureComponent')
    return <div>React.PureComponent: {this.props.render}</div>
  }
 
  shouldComponentUpdate: false
}

https://jsfiddle.net/tynt7te9/1/ pretty cool

@danny-andrews

This comment has been minimized.

Show comment
Hide comment
@danny-andrews

danny-andrews Sep 27, 2017

It's surprising that functional component not PureComponent by default...

Although it's somewhat counter-intuitive, I think it actually makes sense that functional components are not PureComponent by default. The only guarantee (correct me if I'm wrong) React has with functional components that it doesn't have with class-based is that they don't have any internal state. People could still be mutating their props in the wild and relying on their components to re-render, making this a breaking change. (I agree, however, that there should be some way to opt-in to this behavior in the interim.)

danny-andrews commented Sep 27, 2017

It's surprising that functional component not PureComponent by default...

Although it's somewhat counter-intuitive, I think it actually makes sense that functional components are not PureComponent by default. The only guarantee (correct me if I'm wrong) React has with functional components that it doesn't have with class-based is that they don't have any internal state. People could still be mutating their props in the wild and relying on their components to re-render, making this a breaking change. (I agree, however, that there should be some way to opt-in to this behavior in the interim.)

@jonaskello

This comment has been minimized.

Show comment
Hide comment
@jonaskello

jonaskello Apr 5, 2018

Above it is mentioned that in the future there might be a way to opt-in to pure functional components. Is there an issue I can follow to see the progress on this? I've found this issue but it is closed so I guess there is no point to follow along here.

Btw, if such and option would be implemented, I think it would be nice if it could be applied at a global level rather than having to set it on every function.

jonaskello commented Apr 5, 2018

Above it is mentioned that in the future there might be a way to opt-in to pure functional components. Is there an issue I can follow to see the progress on this? I've found this issue but it is closed so I guess there is no point to follow along here.

Btw, if such and option would be implemented, I think it would be nice if it could be applied at a global level rather than having to set it on every function.

@mrchief

This comment has been minimized.

Show comment
Hide comment
@mrchief

mrchief Apr 13, 2018

Recompose.pure is simply a wrapper around React's Component and shallowEqual. Wondering what's the benefit of using that vs just extending Component/PureComponent (and avoid packing extra pounds).

mrchief commented Apr 13, 2018

Recompose.pure is simply a wrapper around React's Component and shallowEqual. Wondering what's the benefit of using that vs just extending Component/PureComponent (and avoid packing extra pounds).

@danny-andrews

This comment has been minimized.

Show comment
Hide comment
@danny-andrews

danny-andrews Jul 13, 2018

My perf benchmarks have found string compares to sometimes be quite slow (just doing string-compares of the prop-names with pre-defined values that we need to handle specially, and that isn't even arbitrarily long data compares).

@jimfb Can you share this benchmark? Maybe things have changed since 2015, but it appears string comparison is quite fast, and the most JS implementations use string interning. https://stackoverflow.com/questions/5276915/do-common-javascript-implementations-use-string-interning

danny-andrews commented Jul 13, 2018

My perf benchmarks have found string compares to sometimes be quite slow (just doing string-compares of the prop-names with pre-defined values that we need to handle specially, and that isn't even arbitrarily long data compares).

@jimfb Can you share this benchmark? Maybe things have changed since 2015, but it appears string comparison is quite fast, and the most JS implementations use string interning. https://stackoverflow.com/questions/5276915/do-common-javascript-implementations-use-string-interning

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment