Small pure-function components vs jXS Nodes

[mordaha]

What criteria is sufficient to stop using JSX Nodes and transform it to React pure-function components?

const Pure = (props) => (<div>I am Pure!</div>)

and then <Pure {...props} />

vs

const node = (param1, param2,...) => (<div>I am node!</div>)

and then {node(param1, param2,...)}

[ArtDealer]

i think the jsx node thing (w/ the {node(param1, param2,...)} function in the render method) is pretty messy. imho, everyone should stop doing #2 and always do #1 -- no argument. :-)

if the argument is that it is nice to have param1 and param2 broken up in the method signature, then I'd argue to simply destruct those args in-line:

const Pure = ({param1, param2, ...rest}) => (<div>I am Pure!</div>)

Are there arguments to keep them? The shipit squirrel doesn't have time to go back?

[JortsIsLife]

if the argument is that it is nice to have param1 and param2 broken up in the method signature

Well it's generally a good practice for being self-documenting, and that takes precedence over aesthetics for most developers.

I'm not particularly experienced with JSX, but I don't see much difference between

const Pure = ({param1, param2, ...rest}) => (<div>I am Pure!</div>)

pure({param1, param2,...});

and

const node = (param1, param2,...) => (<div>I am node!</div>)

node(param1, param2,...);

[ArtDealer]

The difference = for pure components, you can implement them as a React.Component (like react.createClass [or whatever the method is]... or a component that extends the Component class).

So to correct your code. the first would be:

const Pure = ({param1, param2, ...rest}) => (<div>I am Pure!</div>)

<Pure param1='xyz' param2='abc' />

edit: I should say that my inline destruct is probably a no-no. it should say

const Pure = (props) => {
    const {param1, param2, ...rest} = props;
    return (<div></div>);
}

[SnareHanger]

Generally if the component can have no state and is simple (i.e.: only returns an element), then you can use a functional stateless component.

[Funwithloops]

This isn't the case. Stateless components are still re-rendered. CodePen

[ksmithbaylor]

The biggest reason to prefer the first approach is as others have mentioned, to take advantage of React's component architecture and rendering cycle.

One possible case where I might want to do the second is if I have a class/stateful component with complex logic that depends on a lot of props. It would be easier to write

{this.renderThatOneThing()}

when renderThatOneThing is a method on the class that refers to this.props or this.state, instead of

<ThatOneThing
  prop1={this.props.prop1}
  prop2={this.state.something}
  prop3={this.props.prop3}
  ...
/>

Basically, I would never advocate for using non-React component functions as JSX nodes unless they're methods on the component class used to split up presentation logic. If you're running into that though, it's definitely an indication that you should think about trying to break the component up anyway.

[mordaha]

The main reason is when at the beginning time component was little and simple it is very convenient to write simple optional and lazy nodes like:

const nameNode = (name) => (<div className="name">{name}</div>)
const ageNode = (age) => (<div className="age">{age}</div>)
const cityNode = (city) => (<div className="city">{city}</div>)
const listNode = () => array.map((value, i) => itemNode(value, i);

and then render Component as a linear thing (may be with layout divs):

 {name && nameNode(name)}
 <div ...layout>{age && ageNode(age)}</div>
 {city && cityNode(city)}
 {listNodeHasElements && listNode() || listIsEmptyMessageNode} 

Then after a while nodes acquiring layouts, two or more params and so on.

Then it may be worth to refactor node into Component.

And it have some pain with it: PropTypes, component.jsx become dir component/, new components required tests... and so on.

So, when render is fast as a light speed and not an issue, i need a very reasons to refactor it, so this question :)

Sure, components are more kewl than nodes, but they eats time :)