Closed aazuspan closed 1 year ago
I ran some tests and generating the HTML is a significant chunk of the total time for large collections and can actually take longer than getInfo
, so disabling caching on the HTML generation is a no go.
Another alternative I'm looking into is bypassing UUIDs altogether. Currently, UUIDs are used to tie the header <label>
to the hidden <input>
checkbox, but that can also be done by just making the <input>
a child of the <label>
instead of a sibling (see). This would remove any possible interaction between duplicated reprs, save some processing in generating UUIDs, and make the reprs a little lighter.
The challenge is that making the <input>
a child of the <label>
breaks the CSS selector I'm currently using, and I'm not sure there's any well-supported workaround for that. Basically I need to be able to select eerepr-list
elements that are siblings of eerepr-header
elements that contain eerepr-collapser:checked
inputs. The has:()
selector works, but isn't supported by Firefox yet. Instead of relying on pure CSS, I could fix that by injecting some JS into the repr, but I'd like to avoid that if possible to keep things simple.
This is fixed by scrapping UUIDs and connecting label
and input
elements implicitly. I don't think a pure CSS solution is possible without using has:()
which would break Firefox support, so until that changes I'm using JS to handle collapsing behavior.
Collapsing behavior is based on pseudo-random UUIDs generated for each
<ul>
in an objects repr. Because the repr is cached, printing the same object twice will return exactly the same repr with the same UUIDs. When you try to collapse the second repr, the first repr will (probably) get collapsed instead.For some reason, collapsing works correctly in Jupyter classic, Colab, and VS Code, but is broken in Jupyter Lab (including Binder) or when a notebook is rendered statically (nbviewer). I'm guessing this is an implementation detail since the UUID issue isn't platform-dependent.
The quick solution is to cache the Earth Engine data by wrapping
getInfo
instead of caching the repr, but regenerating the repr may be a non-negligible performance hit for huge collections. If performance is too slow I'll need to think about another solution, e.g. caching the repr but re-generating each pair of UUIDs.