Migrate Rankings Table to React

[FinnIckler]

We completely forgot about this one!

This already works fine if we just want to get rid of the bootstrap table. But I think we should also just invest the time and fix up the filters to get the speed boost from not rerendering the page

[FinnIckler]

I added the functionality of filters and loading the data from the frontend.
Styling for the filters are still TODO though

[FinnIckler]

I think removing the segment makes sense

[FinnIckler]

Styled the filters based on the competitions page

[FinnIckler]

Here is the by region view

[FinnIckler]

I think that means I am done?

[kr-matthews]

It takes about a minute to load the data when I change any filters. Is that just a running-locally problem?

[kr-matthews]

This component should be moved to components/wca (maybe in separate PR; the dispatchFilter prop should probably be changed to onChange, since you don't need a reducer/dispatcher to use this reusable component).

[FinnIckler]

It takes about a minute to load the data when I change any filters. Is that just a running-locally problem?

Yes and no. It is quite slow to compute rankings always, which is why we precompute the pages in prod after every cad, but current local state makes it about 5 * worse because of the Debugging output and it also currently serializes the competition object very expensively

[dunkOnIT]

@thewca-bot deploy staging

[FinnIckler]

@thewca-bot deploy staging

[FinnIckler]

It takes about a minute to load the data when I change any filters. Is that just a running-locally problem?

Yes and no. It is quite slow to compute rankings always, which is why we precompute the pages in prod after every cad, but current local state makes it about 5 * worse because of the Debugging output and it also currently serializes the competition object very expensively

Just improved the speed by 10x

[dunkOnIT]

10x speedup sounds amazing!

Two mobile issues:

• Table should be marked unstackable
• Filter buttons overflow their boundary in mobile view (see pic below)

• Issue with region display, see below picture
  

[FinnIckler]

fixed the mobile issues

[dunkOnIT]

Some more issues:

• (fig 1) Have to scroll horizontally to see the results on mobile - we should be able to see at least the name and the time achieved. One option is just making the table wider (see Fig 2 for reference to old table)
• Multi BLD average button shows the round info from when the person achieved the MBLD single oop

Fig 1:

Fig 2:

[kr-matthews]

I'm still confused why there was a duplicate key before - doesn't that mean that a result was showing up in the table twice? I don't understand how switching to react table fixed it either.

[FinnIckler]

I'm still confused why there was a duplicate key before - doesn't that mean that a result was showing up in the table twice? I don't understand how switching to react table fixed it either.

Well I assumed that there was a edge case where the current key wasn't unique enough and react table takes care of that

[FinnIckler]

Also I wasn't just switching to React Table to fix that. I was talking to Gregor and the goal is to use it everywhere

[gregorbg]

Please also merge main so that you can get the linter to rumble about your JSX files 😉

[kr-matthews]

I'm still confused why there was a duplicate key before - doesn't that mean that a result was showing up in the table twice? I don't understand how switching to react table fixed it either.

Well I assumed that there was a edge case where the current key wasn't unique enough and react table takes care of that

My point is that a duplicate key would mean a result was showing up twice, since the key was using the id, which seems wrong - how could such an edge case exist? The switch to react table doesn't change that fact.

[FinnIckler]

I'm still confused why there was a duplicate key before - doesn't that mean that a result was showing up in the table twice? I don't understand how switching to react table fixed it either.

Well I assumed that there was a edge case where the current key wasn't unique enough and react table takes care of that

My point is that a duplicate key would mean a result was showing up twice, since the key was using the id, which seems wrong - how could such an edge case exist? The switch to react table doesn't change that fact.

Did you actually see any duplicate results? I assume this is a problem with the query when one average contains two singles that are shown in the results view. I can dig deeper tomorrow

[kr-matthews]

Did you actually see any duplicate results? I assume this is a problem with the query when one average contains two singles that are shown in the results view. I can dig deeper tomorrow

No, but I didn't look very closely/carefully. This was for displaying 3x3x3 single. If the id of a result is coming from the average, then that could explain it. But in that case, it indicates that the key needs to be updated. If moving to react table has resolved the issue, despite a duplicate key existing, then surely it's not using the key and we can remove the key (I see it's still in the code)? (And if it is using the key, then how is it not getting duplicates?)

Basically, it might (currently) work, but there's definitely a (potentially minor) underlying issue somewhere, because the key isn't unique.