2

I'm new to React and I'm trying to make a Data Grid, it's working by now but I feel like I'm doing it wrong, here are the details:

Each row has multiple input (text, select, button), and we have the ability to delete, insert rows.

Now I have a GridComponent that holds all the data as an array of objects. On render it will pass the object to RowComponent with a handle to call when the input changes:

this.state.data.map((rowdata, index) => 
    <RowComponent 
       key={rowdata.id} 
       rowdata={rowdata} 
       dataindex={index} 
       handleChange={this.handleChange} 
    />
) 

The problem is when RowComponent calls handleChange, the GridComponent uses the rowindex to update the object. But it's slow and has a little delay while typing.

To solve that problem I then declare a state in RowComponent to control the data while typing and only call handleChange on the onBlur event and it's working very well. But now I have 2 states in the Grid and Row, is it the correct way to do it?

hypnagogia
  • 173
  • 3
  • 16
Tubc
  • 416
  • 3
  • 19
  • Both approaches should be fine. How big is the data we're talking about though? Does id change for any reason? – Horia Coman May 08 '17 at 10:00
  • You are not using anything like flux or redux? – Anthony Kong May 08 '17 at 10:08
  • @HoriaComan : It will not too big just curious because the first approach is slow and the second is duplicate the data. the id is just for key – Tubc May 08 '17 at 10:13
  • @AnthonyKong I've heard about it but it's just a simple app so I haven't look at those two. – Tubc May 08 '17 at 10:15
  • If you have a centralised store then you do not need to worry about keeping two consistent copies of the same state. Save you a lot of trouble down the road. – Anthony Kong May 08 '17 at 10:18
  • @Tubc true, but _how_ big? If we're talking 1000s of elements, that might put enough pressure on React and DOM manipulation that you'd see performance problems. Even if the data is itself small. Wrt the id, it's important for it to stay the same through the lifetime of the component, so React doesn't recreate the components involved on a new render. – Horia Coman May 08 '17 at 11:49

1 Answers1

1

Have you profiled your code to identify the slowest pieces?

You seem to have done this in an acceptable fashion without using flux. This should be an issue with lots of frequent and preventable renders. Mostly a matter of putting some shouldComponentUpdate checks. Unless you fix these, externalizing state will not help (except for libraries which use forceUpdate based approaches, like MobX).

Also, for inputs you should prefer having either debounced event handlers, or having a shadow internal state (like you have done), over propogating all changes immediately.

Community
  • 1
  • 1
hazardous
  • 10,627
  • 2
  • 40
  • 52
  • 1
    Thank you, the suggestion to profile the code and use shouldComponentUpdate was really helpful. I understand react more now, really appreciate your answer – Tubc May 13 '17 at 07:03