enhancement: Speed up the trades table by only rendering rows that change

[steveluscher]

trafficstars

In this PR we make a change to the public trades table that reduces its time-to-update by up to 10x.

Before, the update of a single row would cause the entire table to re-render.

After applying a memoization technique, only new rows cause a render pass; existing rows are left alone.

[steveluscher]

Is this interesting to you at all, @armaniferrante? Happy to keep digging for more performance opportunities if so!

[BunnyNomics101]

We will be happy to know more

[steveluscher]

Great! Anything you need before being able to merge this, @BunnyNomics101?

[BunnyNomics101]

Great! Anything you need before being able to merge this, @BunnyNomics101?

@steveluscher Thanks Steve, wouldn't this mess up the chronological order or price order of the public trades table?

[steveluscher]

…wouldn't this mess up the chronological order or price order of the public trades table?

It won't! React keys are not used for ordering, they're used for identity.

Identity is important, because it tells you when something moved rather than changed.

Imagine you started from a list that looked like this.

C
B
A

Without keys, an update that added D and pushed A off the end of the list would appear as though every row changed, from React's point of view.

D  <-- changed from C
C  <-- changed from B
B  <-- changed from A

When you add keys, React is all of a sudden able to tell the difference between a change and a move.

D(key=D)  <-- added
C(key=C)  <-- moved from position 0 to 1
B(key=B)  <-- moved from position 1 to 2

In this PR, we take rows that used to have unstable keys that would change from update to update, to having rows with stable keys that last for the lifetime of that row's presence in the UI.

[BunnyNomics101]

…wouldn't this mess up the chronological order or price order of the public trades table?

It won't! React keys are not used for ordering, they're used for identity.

Identity is important, because it tells you when something moved rather than changed.

Imagine you started from a list that looked like this.

C
B
A

Without keys, an update that added D and pushed A off the end of the list would appear as though every row changed, from React's point of view.

D  <-- changed from C
C  <-- changed from B
B  <-- changed from A

When you add keys, React is all of a sudden able to tell the difference between a change and a move.

D(key=D)  <-- added
C(key=C)  <-- moved from position 0 to 1
B(key=B)  <-- moved from position 1 to 2

In this PR, we take rows that used to have unstable keys that would change from update to update, to having rows with stable keys that last for the lifetime of that row's presence in the UI.

@steveluscher Ah, very nice explanation so that explains the 'keys'.

We are building on a fork from the serum-dex-ui: https://github.com/BunnyNomics101/Sobull.git

And we would really love to have your input as a dev. We want to migrate to inferno.js (almost same as react.js) for even faster performance. Maybe even flutter.

Would you like to help us with this (for a compensation too)? Email: [email protected]

It would really be fun to try and push this orderbook into max performance. We are currently working on a web socket for faster real-time + sync for our charts and tx history/balance display!

[steveluscher]

We want to migrate to inferno.js…

Oh neat! I worked with the person who made Inferno. Super nice guy.

I would not bet against React, at this point in time. Since keys, there have been a lot of performance-focused features introduced to React – some just within the last year – and there are many more to come.