Pure Components

[mthadley]

It seems like it would be useful to have the pure render logic in metal-redux available outside of that library. React had a mixin available for this, and we could create some kind of similar module that developers can use, but I also wonder if it is something that would be good to have at the framework level?

It could still be something that is disabled by default, since the component developer needs to be aware of any mutations they might be performing on component configs attributes. However, it would be very convenient to just write something like this:

class MyComponent extends component {
  render() {
    // ...
  }
}

MyComponent.pureRender = true;

We could also go further and make function components have this behavior enabled by default. I believe I read something somewhere that the React developers were thinking about doing this for their functional components as well.

[mairatma]

You're right, this would be a good addition :)

[mairatma]

This issue was moved to #8

[mairatma]

This issue was moved back.

[mthadley]

So after coming back to this and understanding more about metal-state, I'm wondering how useful this would be.

As some background, React will always re-render when setState is called, even if the same value is passed each time. This is true for even primitive types like numbers and strings. So as an example, calling setState({count: 3}) every time a button is clicked means React will re-ender three times. My assumption was that Metal would do the same. For React, to get around this, you must opt in by extending from PureComponent instead, or implementing shouldComponentUpdate in some way.

However, while metal components will update whenever the state changes (stateChange), that event will not be emitted if the values are the same (objects are handled differently, due to mutability). So in the example from before where we call setState({count: 3}) three times, Metal would only render once, without any special configuration needed.

TLDR: Metal is already implementing the behavior that I originally was hoping to add. The only thing to add here is to possibly extend the equality check to objects as well. The developer would still have to opt-in via some kind of PURE flag, and it would mostly be useful for developers who are using immutable data structures.

@mairatma Does this sound correct? Because this would be such a fringe use case, and increased chances of bugs, I'm thinking this is something that should not be added to the core API.

[mairatma]

@mthadley yes, this makes total sense. It might still be useful to have something like this, so that projects using immutable data can use it, but I agree that it shouldn't be part of the core, it could be a separate utility module instead.

[mthadley]

I agree, so I'm going to close this issue here. Thanks!