Track viewed tabs in TabWidget component

[magland]

This was discussed in #142

With this PR: In tab widget, tab content is not removed from DOM when switching between tabs, but also the tab content is not included in the DOM until the tab was viewed at least once. This involves keeping a state tabsThatHaveBeenViewed.

To verify this is working:

• Run sampling and click on ANALYSIS (PY) tab
• Resize the editor
• Switch to the OUPUT tab and then back to the ANALYSIS tab
• Note that the resize has persisted

Then for a second test:

• Run sampling and wait for a few seconds
• In the OUTPUT tab, click HISTOGRAMS tab
• Note that plotly is being loaded, demonstrating that it hadn't been loaded previously.

[WardBrian]

A few thoughts on the implementation of this. I agree it’s the right thing to do in general

[WardBrian]

Thoughts on using a boolean[] of the same length as labels, rather than a number[]?

[magland]

@WardBrian I made all your suggested changes/simplifications, except for your changing the state type to boolean[]. I think it's cleaner as number[] because

• More natural to initialize as []
• May want to accommodate dynamic changes to number of tabs in future (at that point we'd want to use tab IDs rather than indexes)
• State updates should create immutable objects. It's more natural to update a list compared with updating an entry in a boolean[] in an immutable way.

[jsoules]

@WardBrian I made all your suggested changes/simplifications, except for your changing the state type to boolean[]. I think it's cleaner as number[] because

* More natural to initialize as []

* May want to accommodate dynamic changes to number of tabs in future (at that point we'd want to use tab IDs rather than indexes)

* State updates should create immutable objects. It's more natural to update a list compared with updating an entry in a boolean[] in an immutable way.

An additional possibility would be to just use a string[] whose values are the labels. If we are planning for the situation where tabs might be dynamic, we might also want to support reordering, which would be difficult with an index-based or order-based numeric ID.

But I don't really feel too strongly about this--I think it'll be easy enough to adapt the solution if we ever decide to support those features.

[WardBrian]

Yeah, I'm happy with the current solution and the options we have for crossing-bridges-should-we-come-to-them

[WardBrian]

Also note, re #142, it appears that while the tab stays mounted, as you observe with the splitters maintaining their states, the pyodide worker does seem to terminate still. I think there is a separate set of changes deeper in the call stack needed to fix that, but I'm also planning on proposing some refactors to those component's organization that I think would fix it anyway.

So besides the one comment above I think this can be merged as-is