Micro Dive Into React Solution for Tables

Jeren Hicks

Warning:

This solution is still considered a prototype and currently still being evaluated. Code and examples seen within may still be of a prototype example. This solution may be abandoned down the road should things not work out. Please take this into account. Nothing is final...yet.

The Problem

Constant complaining for two years on query speed
New SCR to look on some how speeding up the queries, mostly through use of client side caching.
Query results were easily taking 45+ seconds to complete.
Server call times only a fraction of the time
Unclass side rarely saw this problem.
Secret only barely saw the problem.

Hunting for a Solution, Part 1

W2UI
- Much faster than vanilla backbone.
- Deferred rendering helped a ton
- Deferred rendering hide the major problem from us.
- While we gained speed over just vanilla backbone, we were still slow.
Performance pass
- Cleaned up a lot of logic to help improve performance.
- While significant, not the 'magic bullet'

Hunting for a Solution, Part 2

Model investigation
- Clean up and improve the results object to load faster.
- While a good pass, this did not net a big enough change
Cacheing
- Several solutions investigated, however they all come with 'problems'.
- This did not fix the underlying problem

Hunting for a Solution, Part 3, the finale

Rendering investigation
- Took metrics of what the actual system was running with.
- Became very apparent very quickly the browser was spending a lot of time rerendering.
- Each object was causing the browser to rerender.
- If 10,000 results come in, the browser rerendered the table 10,000 times!

The ultimate problem

While w2UI fixed a lot of problems we had from the past, the solution as a whole did not perform well on an actual data set of 10,000+ results.
While w2ui did a lot of what we were wanting, it was ultimately not going to be able to be maintained as the ultimate solution.

The hunt for a solution...

Cacheing
- Still is being considered, possibly to address further issues down the road if new speeds aren't good enough.
Raw JSON
- Instead of pulling the json from the services in and turning them into models, just pass around raw JSON.
- Bad option on multiple fronts, but would alleviate some problems.
Change table library

The choice

Investigate React Framework
- Designed to allow very fast changes to the DOM via the virtual dom.
- Only changes the things that needs to be changed, instead of the entire container or page.
- Easily slots into our existing frameworks
- New, more modern framework that focuses on speed and performance.

Accessing a success

Wayne and I discussed several ways to evaluate solutions, here are a few:
- Solution must get rendering times down to ~1 second.
- Must sort and filter.
- Must be able to be styled closed to the w2ui solution.
- Handle 10,000+ rows

TOO MANY CHOICES!!!!11

Table by Jeren
- It worked... <_<
- Not optimized very well
- Tests only showed about a 50% decrease in time
React Table
- Fast and lightweight. Ton of features
- Tests showed improvement of time, but still not great.
- Not deferred render
React Data Grid
- Proven to handle large data sets (1 million row example)
- Fast processing of filters (return of the dynamic filter)
- Quick sorting

The good choice

React Data Grid
- Choosen because of the speed of handling massive rows.
- Million row example really shows it's power.
- Possibly easiest to implement

The results...

Easily handles 10,000+ rows.
Return of the dynamic filtering.
Sorting and filtering are quick!
Rendering speed currently around 1.5 seconds

Where to go from here...

This solution should NOT be used every where there are w2ui tables...
Choose places appropriately. It will take some time to switch things over.
Focus on areas where high volume data comes in, or where you want very responsive sorts and filters.
Currently only found on mode...
React is now open to you...

Let's look at the solution...

Where are we going from here?

Currently deployed on mpacs-dev and secret side. Hoping to get sent down to base "soon"
Clean up code and continue to harden.
Figure out how to get React into 'production mode'. Likely gain more performance from this.
Likely full solution 'ready to go' by end of sprint.