Only if you did that in the render function.

If you did this.foo = this.foo.bind(this, props.bar) in the constructor then it would be the same function each time.

For this specific example you don't have access to the list index in the constructor.

In general binding like that in the constructor works only if you depend on props, but at that point, there isn't a need to bind at all since you can just reference the prop in the callback.

If you do that in the parent constructor it only really works for a single child and then you're better off not partially evaluating and instead having it pull props.bar at execution time

Sure, it would be an odd pattern but perhaps a required one for a certain interface.

eg: it's going to be used as a event callback but you want the function signature to be foo(bar, event). Then you get the benefits of partial application without the problems of currying a new function each time its called.

source: have used this a lot for event handlers, especially when dealing with on 3rd party code.

I don't quite understand. The interface is the same. I guess if the function you're binding is an external 3rd party one then you avoid proxying through a local function first. But there's no difference from the point of view of the child.

I guess my point was that it doesn't scale to multiple children (which is effectively what the question was about). And whether you want to partially apply a bound function in the constructor or just bind and then have the function pick up the extra arg itself - it's the same thing. You end up with a single function that works with a single constant.

Though, in your case if props change, the partially applied function is now incorrect. Which is why I think I'm misunderstanding you.

Right, I just used `props.bar` in that example, you're right - it would be a bad idea to do so unless it was some kind of initializing prop (common with state-based stuff).

> The interface is the same.

Huh? foo(event) is different from foo(bar, event) and if your function is only ever going to be called with the former (ie - any dom event handler) and you want the latter... it's absolutely useful.

I rather meant the interface between the partially applied foo and the version of foo that plucks bar from props when it's called.

Anyway, I see what you mean and it's a perfectly reasonable thing to do. Doesn't solve the original issue that was being discussed though :-)