https://www.loom.com/share/f40ed77eb2db4d4e99d0479d701a7024?sid=ba0facce-6afb-4139-9bcd-d167272948cf

This is a more recent example of this.

When inspecting a step with a large input/output data clip, the page takes a moment to load and could possibly crash. See image below.

How to replicate the latest issue :
when I click back and forth between Input and Output, the page either is really slow to load or even crashes.
when I click into Output it says No output state could be saved for this run. what does that mean? when/why does that happen?
Then I try clicking the step E0 Get Donors CSVs from SFTP and it takes so long for the inputs/outputs for this step to load

I had a discussion with @stuartc on this and the plan is to have a REST endpoint that returns a dataclip body which is then loaded using a react-window lib. This has been inspired by this blog: https://blog.logrocket.com/render-large-lists-react-5-methods-examples/

Also to consider is how we can do caching via http: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#private_caches

@midigofrank , @stuartc , great to hear progress on this one.

I'd like to note that a key bit of UX should be preserved in this solution and it may be hard to accomplish if I understand your current thinking:

• When users go to look at a run with 40,000 lines of text, they'd like to be able to find a specific line using control-f in the browser or control-f in monaco.
• How can we ensure that if only 1,000 lines are loaded at a time, they're still able to find the line that contains the string logging client id: aMidigoInAHaystack ?

@taylordowns2000 we've tested the react-window library and it seems we can't do a control-f because it renders the elements on demand.

We decided to give monaco a try since it provides it's own search interface.

@midigofrank , standardizing all of our code interfaces (expression-editor, log-viewer, input/output-viewer, and input-creator) around Monaco feels like a win, anyway. Excited to hear how the spike here goes.