Material-ui: [TextField] Improve rendering performance

[kodermax]

When i quickly write text, textfield slowly.

[nathanmarks]

I believe that the underline and floating label are culprits here, they appear to re-render and waste time on every change.

[nathanmarks]

@newoga

I did some investigation with a benchmarking test that I mentioned in #3289 .

A lot of these issues come back to the styles performance issue. So would I be correct in assuming that this stuff falls under the umbrella of @alitaheri's issue here #3248 ?

[newoga]

A lot of these issues come back to the styles performance issue.

Not too surprising! This needs to get fixed.

So would I be correct in assuming that this stuff falls under the umbrella of @alitaheri's issue here #3248 ?

Yeah, I consider #3248 the first step towards improving performance (as it relates to styling) that we're going to try to get in the next release. Obviously @alitaheri understands a lot better then ins and outs of the implementation and what we can expect performance improvement wise. I'd love to see if we can implement some his ideas in TextField to see how it impacts the benchmarks you are collecting.

[nathanmarks]

The underline no longer wastes time if I use pure(), but the label ends up doubling the number of instances when you use pure() because of the styles. I'd think this also contributes to long mount times for lists etc...

[newoga]

I think we should consider removing defaultProps from those two components and maybe setup the defaults on the props destructure within render. If we do so, we might be able to take advantage of recompose's optimizations when it detects the component is referentially transparent.

I've been meaning to test this, could you try it and see if it makes a difference on TextField?

Edit: If it doesn't work through recompose, we may have luck implementing it ourselves in TextField.jsx

[nathanmarks]

@newoga I can certainly test that.

[newoga]

@newoga I can certainly test that.

Awesome, thanks @nathanmarks! Hopefully it works/helps :sweat_smile:

[newoga]

By the way, @nathanmarks: There was a really interesting talk at React conf by Netflix relating to this. I'm not sure if you saw it. When it shows up on YouTube, I'll send it to you.

Edit: More specifically relating to HOCs including the performance implications and optimizations that can be done.

[nathanmarks]

@newoga Oh man, I definitely need to see that! I have done a fair bit of testing with HoCs and seen some scary jumps in a couple of numbers. It's a difficult balance to get right in a large application or library where you want to promote re-use but keep things performant and not bring the entire kitchen sink everywhere with you.

[nathanmarks]

@newoga https://www.youtube.com/watch?v=kDARP5QZ6nU

That the one?

[newoga]

Yup that's it, glad you found it!

[nathanmarks]

edit spoke to soon

[oliroy]

Is there an ETA on this? On react 0.15.1.0 and Material-UI 0.15.0 this is still an outstanding issue. Performance is very poor all around when binding a TextInput to a state property and having it update on the onChange event. The work around I am aware of is to use refs on inputs which becomes a anti pattern when implementing live client side validation.

[laispace]

@oliroy +1

[oliviertassinari]

We have been porting the component on the v1-alpha branch. We reimplemented it from the ground-up. While we haven't tested it, I think that the issue is most likely fixed on that branch. Hence, I'm closing it.

[jackson-sandland]

Still an issue...

[mbrookes]

@jackson-sandland Still an issue with what version?

[oliviertassinari]

@jackson-sandland Do you have a reproduction, or a benchmark?