More lazy loading of react components to reduce bundle size

[cmdcolin]

Currently loading the page load

• For start screen incurs 3.8MB js to be downloaded
• For a page direct to an LGV with a track incurs about 7.4MB js

This PR does not help too much yet but I thought some more work to reduce JS size could be beneficial

• Making some of the NewSessionCard images smaller and runs pngquant on them (low hanging fruit, can be made a separate PR probably)
• (Re-) introducing the LazyReactComponent option for ViewType, which could be expanded upon. I added LazyReactComponent for circular, dotplot, and spreadsheet
• For spreadsheet in particular, tries to lazy load the parsers since csvtojson dependency is ~160kb
• Makes dotplot/circular/spreadsheet not use jbrequire just for simplicity and since it doesn't appear needed

Note that the lazy loading isn't paying off big yet but I think it could help in the long run cut our load times

Current payloads with this PR

• For a page direct to an LGV with a track 6.4MB (delta -1MB)
• For a start screen 3.3MB (delta -0.5MB)

[cmdcolin]

sv inspector needs a fix to use LazyReactComponent so that's on the todo, note still draft PR

[cmdcolin]

MB size calculated by filtering on /.js$/ in the network tab in chrome

[cmdcolin]

Some new figures made by kicking some of the widget code into lazy loading

• LGV with track loaded 5.4MB (delta -2MB)
• Empty session 2.8MB (delta -1MB)

[codecov]

Codecov Report

Merging #1888 (2a985e0) into main (c531991) will decrease coverage by 0.53%.
The diff coverage is 36.20%.

@@            Coverage Diff             @@
##             main    #1888      +/-   ##
==========================================
- Coverage   58.13%   57.59%   -0.54%     
==========================================
  Files         461      458       -3     
  Lines       21488    21342     -146     
  Branches     5102     5094       -8     
==========================================
- Hits        12491    12291     -200     
- Misses       8686     8741      +55     
+ Partials      311      310       -1     

Impacted Files	Coverage Δ
packages/core/BaseFeatureWidget/index.ts	75.00% <ø> (ø)
packages/core/PluginManager.ts	94.23% <ø> (ø)
packages/core/pluggableElementTypes/ViewType.ts	81.81% <ø> (ø)
packages/core/pluggableElementTypes/WidgetType.ts	81.81% <ø> (ø)
...ore/pluggableElementTypes/models/BaseTrackModel.ts	33.72% <ø> (-3.65%)	⬇️
packages/core/ui/Drawer.js	100.00% <ø> (ø)
packages/core/ui/RecentSessionCard.js	14.28% <ø> (ø)
packages/core/ui/Tooltip.tsx	15.38% <ø> (-11.29%)	⬇️
packages/core/util/types/index.ts	61.53% <ø> (ø)
...ns/alignments/src/AlignmentsFeatureDetail/index.js	75.00% <ø> (ø)
... and 105 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c531991...2a985e0. Read the comment docs.

[cmdcolin]

Appears to need fixing for plugin builds, tried adding inlineDynamicImports to the packages/development-tools rollup config but not there yet. That does imply plugin builds wouldn't use code splitting

Also there is an alt branch that extends this PR by making data adapters import their parsers on the fly too
lazyreact...lazyreact_dataadapters

That makes it so that for example you don't import the @gmod/bam until you actually load a BAM track (The BamAdapter is actually still loaded, but the @gmod/bam is delayed...there may be another way to approach that too that doesn't require so much digging into the data adapters where the adapter itself is lazily loaded)

[garrettjstevens]

I haven't had a chance to go through this thoroughly yet, but see a couple initial comments. Also a couple questions:

• If e.g. a widget's ReactComponent is not lazy, will the Suspense handle that ok?
• Does this mean that any product that uses e.g. a plugin with a ViewType will need to wrap the ReactComponent in a Suspense? Can we make TypeScript aware of that by e.g. using LazyExoticComponent in the ViewType.ts base class?

[cmdcolin]

If e.g. a widget's ReactComponent is not lazy, will the Suspense handle that ok?

yes, the Suspense is pretty flexible, see here https://reactjs.org/docs/code-splitting.html (specifically how normal jsx, and several lazy components are in that one example)

Does this mean that any product that uses e.g. a plugin with a ViewType will need to wrap the ReactComponent in a Suspense? Can we make TypeScript aware of that by e.g. using LazyExoticComponent in the ViewType.ts base class?

I think that is a good idea, testing it out now...

[cmdcolin]

Ended up needing, at least from cursory look, LazyExoticComponent<React.FC<...>>|React.FC<...> to properly type it being lazy or not

[rbuels]

A few little nits to pick, comments and questions, but ok to merge as is.

[rbuels]

just curious, why is this needed?

[cmdcolin]

I moved packages/core/ui/StartScreen.tsx to products/jbrowse-desktop/src/StartScreen.tsx and correspondingly needed to move a declare.d.ts for this item there

[cmdcolin]

I did this because jbrowse-web already had it's own specialized StartScreen so I figured there was no need to have one in core