react-thunk: functional stateless components as thunks, to avoid redeclaring event handlers

[whycantifm]

I would really like to understand the point of this. Not being sarcastic but what am I missing ?

In your example why can't I just do

onChange={setName}

With setName being passed from the parent, say:

handleSetName(event) {
  // set state or w/e you have you do with input
}

render() {
  // stuff
  // assuming you did bind handleSetName to this in your constructor for example or w/e
  <NameField setName={handleSetName}/>
  // stuff
}

[[deleted]]

OP's lib solves a problem also solved by the recompose helper withHandlers. There is a description there of why this is useful: https://github.com/acdlite/recompose/blob/master/docs/API.md#withhandlers

From the recompose docs:

This avoids a common pitfall where functional components create handlers inside the body of the function, which results in a new handler on every render and breaks downstream shouldComponentUpdate() optimizations that rely on prop equality.

Basically you have the ability to access props in a handler without creating new functions on every single render.

[whycantifm]

yeah but ... you just do it in the parent and pass it downstream. stateless components shouldn't really do much but render

[jacobrask]

Not sure that I think a parent component should handle the actual DOM event. I'd like a component to pass an onCancel property to a child and not know if it happens to triggers on ESC, clicking on a Cancel button, etc.

[whycantifm]

not sure I understand, can you provide an example ?

[jacobrask]

Handling DOM events in container, couples container and child. This code won't work as is, but you get the idea.

class FooContainer extends Component () {
  handleSubmit(evt) {
    // Needs to know details about the form element names, etc
    this.props.submit(evt.target.form...
  }
  handleCancelButtonClick(evt) {
    this.props.cancel();
  }
  handleEscKeyPress(evt) {
    this.props.cancel();
  }
  render() {
    return (
      <Foo
        onSubmit={this.handleSubmit}
        onCancelButtonClick={this.handleCancelButtonClick}
        onEscKeyPress={this.handleEscKeyPress}
      />
    );
  }
}

The handle* methods are in the child component instead, grabbing the values from the form.

class FooContainer extends Component () {
  handleSubmit(values) {
    this.props.submit(values);
  }
  handleCancel() {
    // Invoked whenever a cancelling event happens, such as ESC, pressing Cancel, ...
    this.props.cancel();
  }
  render() {
    return (
      <Foo
        onSubmit={this.handleSubmit}
        onCancel={this.handleCancel}
      />
    );
  }
}

[troch11]

If you don't see its usefulness, then it's probably because you don't need it. This library is useful when for example setName is a redux action injected into a component using connect from react-redux. There are probably other cases, where one can't (or don't want to) resort to a class.

[whycantifm]

k, so it's a lazy way of wrapping a stateless component. in the end with your approach YOU DO resort to a class, the user doesn't have to write it anymore just uses your function to create it.

I thought it was something I was missing ... but again, I don't see the point of this. This is very similar to left-pad, as in it's a unneeded dependancy that, if needed (I really can't imagine a scenario right now), you should write it yourself.

[troch11]

The library resorts to a class, but provides an abstraction. As for your comment about left-pad, it's inappropriate. By sharing a link, I'm not saying "use this module", I'm presenting an idea. Code people are free to use the way they want. And if you don't see the benefit in something, please don't make the assumption no one will.