Display Throughput and Progress Bar in Sync UI

[evantahler]

Extracted from #18630, part of https://github.com/airbytehq/airbyte-internal-issues/issues/1095.

This PR contains the UI changes for displaying Throughput metrics and Progress Bars once the APIs are updated.

Interesting Tidbits:

• Progressive Enhancment!
  • Until the APIs are updated, the UI looks the same as it does today - it is safe to merge this now
  • If we don't get estimate data (e.g. estimated_bytes and estimated_records) we can still display throughput information for the running sync
  • If we get estimate data for only the total sync, we can show the progress bar
  • If we get estimate data per-stream, we can show the progress bar and an optional drill-down for the % complete and throughput for each stream
• Extracted formatBytes into utility file (utils/numberHelper)

---

While @davinchia is working on the API, you can run this branch against a mock data api that returns random values for sync data:

git checkout davinchia/mock-data-backend && git merge evan/ui-throughput-and-progress

[timroes]

Gave this a quick initial view. Will continue with a more in detail review, once the larger topics are addressed.

[evantahler]

@timroes - everything addressed except for the progress bar component.

Can you please share a little more about the desire to in-house the progress bar SVG component rather than using a library? They do some pretty cool things with opacity and transitions (https://github.com/react-component/progress/blob/master/src/Line.tsx) which I'd rather not redo. Do you want me to vendor the component maybe?

[timroes]

@evantahler The reason behind this is that you usually try to avoid micro libraries as dependencies in projects. This file has 100 lines, and if we'd strip out what we don't need because of the properties we use it's more like 60 lines. Pulling in a library for that small amount of (specifically) very simple code is usually something you want to avoid. JS already has a dependency problem, by having way too many dependencies (of dependencies). Just to give you an idea: our webapp atm pulls in roughly 3850 npm modules (some of them duplicates in different versions). That's not good. Each of those libraries needs to be updated, can have security issues, or break your build at some point randomly. If you're not familiar with "leftpad gate" I'd recommend giving https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code a read (basically one 11 line npm library, broke the whole JS ecosystem for a day or two, and unfortunately wasn't the only time this happened).

Thus the rule for pulling in a library should be:

(a) is the code complex enough that we want to "outsource" it over maintaining it ourselves (not the case here imho), or
(b) if the code is simple, is it of a nature that it is expected to change and we'd want someone else to do those updates, e.g. we could have embedded country flags for the multi cloud selector into our code directly. But it's just easier using there a well established library, that we know will keep flags up to date if they'd change, or similar for time zone data.

[evantahler]

Custom progress bar implemented!

[evantahler]

Updated screen shots with custom components using mock data (per the git instructions above)

[timroes]

---

Sorry did approve the wrong PR :D

[timroes]

I'm picking this up to finalize this code wise and design wise. I'll turn it back to a draft PR while working on this, so it's more clear this is still WIP, and I can commit WIP states to it.

[timroes]

After syncing with some other FE devs, we decided to have the default collapsed state to be as minimal as possible, i.e. showing only the progress bar, tim estimate and percentage, in an effort to try to unclutter our UI in general in the future:

When you expand a sync we'll show a more detailed view, which contains the state of all the streams affected, including their progress (or no progress dial if they don't have progress). We'll always move completed streams to the end of the list to be out of the way. Hovering over a stream will give a tooltip with more detailed information about this stream:

[timroes]

@evantahler could you give this another look if this seems to work for you (I tried not to touch any of the calculations as much as possible to not break them). You'd need to remove https://github.com/airbytehq/airbyte/pull/19193/files#diff-ea2eee4433bb43b0729c75ac3869e6d53de2335e6b8b98dfad9785f6ae514ef0R20-R205 before testing with real data. I left it in for now, to make it easier to review for other FE people.

[timroes]

ℹ️ Needed so that eslint doesn't complain anymore that style needs to be an object on FormattedNumber (where it doesn't need to be an object actually).

[evantahler]

@timroes this is amazing! Thank you! I have no notes and the tooltips are awesome.

If you want to remove your hard-coded stream data and see the bars move, you can git checkout davinchia/mock-data-backend && git merge evan/ui-throughput-and-progress and run the platform from there - this is mock APIs

[krishnaglick]

Looks like there may be an issue with the build when merged into Davin's work.

[evantahler]

So... what's the status here? Can this be merged now?

[timroes]

Still awaiting a review from someone from Platform Workflow. @tealjulia @edmundito @krishnaglick would appreciate if someone could review this.

[krishnaglick]

Sorry, this slipped my mind. I’ll jump on it tomorrow!

…

On Thu, Dec 1, 2022 at 7:24 PM Tim Roes ***@***.***> wrote: Still awaiting a review from someone from Platform Workflow. @tealjulia <https://github.com/tealjulia> @edmundito <https://github.com/edmundito> @krishnaglick <https://github.com/krishnaglick> would appreciate if someone could review this. — Reply to this email directly, view it on GitHub <#19193 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABF42DRNFWNQLFJIKTMZ6BLWLE6SBANCNFSM6AAAAAAR25CY7U> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[krishnaglick]

I have not spotted any regressions from this change and the UI can be revisited if necessary when the API is more feature complete.

[evantahler]

Let's go!

I'll fix the merge conflicts and merge!