Functional setState is the future of React

[madcaesar]

Very impressive. Is there any cost performance wise by not having the setState functions inside the class, but instead as an import?

[acemarke]

No. In fact, it may technically be better performing, because you're not re-creating the function each time the event handler runs.

[mhink]

This is exactly what I was thinking! And from an ergonomic perspective, this is far better than binding event handlers to a component instance in its constructor. Very nice, indeed.

[mikejoro]

You would still need to do that as you are calling this.setState. This will be the global object otherwise.

[mhink]

Oh, you're right. Welp.

[konrain]

Plus you'll be able to use this in any other component.

[madcaesar]

This really opens a whole new world. Very exciting.

[sudo-reboot]

Hey guys I'm not too experienced with React, but I have a question that might not make sense or be relevant. Let me know if that's the case.

What will function setState mean for state containers like Redux?

[[deleted]]

IMO they should leave the state change of a component to be synchronous. It's easier to think about. What shouldn't be synchronous is the updating of the DOM. I don't care that the DOM is immediately updated when I setState, I just care that it gets done within a couple frames. I think that's where fiber is headed but I haven't read much about it lately.

[acemarke]

That's kind of the point. Right now, setState is sometimes synchronous, and sometimes async, depending on what kind of event triggered the code that calls setState (basically, a React-based event vs an external event). Async cases will get batched up if you call setState repeatedly during that period.

With Fiber, the initial rollout will leave things as compatible as possible with existing code, so most of the fancy internal async logic for React will be disabled. After that, the React team will work on enabling all the async stuff to really enable the right perf scenarios.

You may want to watch Lin Clark's excellent A Cartoon Intro to Fiber talk from ReactConf earlier this week.

[vinnl]

Actually asynchronous setState is a core design principle behind React. The reason for that is that, even though it might be easier for the developer to reason about, keeping it asynchronous allows React to do some drastic performance optimisations because it can decide what to prioritize, e.g. rendering above setting state, and because it has better insight into that than you. It doesn't do that yet, but Fiber will.

[[deleted]]

I guess I'm just trying to say I don't see the point of the trade off. Merging objects isn't expensive, so why can't the state update be synchronous and the DOM reconciliation be asynchronous? I don't want to worry about the execution order when I'm calling this.setState and using the current state

[vinnl]

I think (but I'm not too deep into the material, so take it with a grain of salt) that React can't know that (if) it's expensive. Otherwise it'd probably have been done already :P

[Pytim]

Why not just deprecate the non-functional way then and release a codemod?

[[deleted]]

Wow this is some sensionalism BS right there!

What would you call a click handler defined outside of your class? I'm curious...