I realised that the mockValues and mockMetadata objects were not properly tree-shaken in consumer applications of @h5web/lib or @h5web/app (at least with ones using Vite as their bundler). As a result, those two giant data structures were being created on every page load of myHDF5, just to name one.
Tree-shaking works better (only?) with functions, so the idea is to turn mockValues and mockMetadata into functions. This has benefits even in projects that do need these two structures (e.g. in the demo project), since it means that we can generate them lazily, when they are actually needed (e.g. when navigating to the mock demo).
I had tried to generate the mock metadata and values lazily before, but never really got to a point that I found satisfactory. The API to access or generate entities and arrays that we use in our Jest test suites and in the Storybook was always quite convoluted.
This time, I had the idea of generating ndarrays instead of plain, nested JS arrays in mockValues, which unlocked a lot of things, thanks to the simple fact that ndarrays store the shape of their underlying arrays. For instance, this means that we:
no longer need to hard code the dimensions of our mock arrays everywhere (like [20, 41]...) when we generate the mock metadata;
no longer need to find a mock dataset's metadata (just so we can know its shape) in order to construct an ndarray from its value.
Additionally, since the internal array inside an ndarray is already flattened, we no longer need to deal with this in MockApi.
The PR is huge particularly because I took the opportunity to clean the metadata a bit and to shorten the metadata utility functions to make the whole thing a bit more readable.
axelboc
commented
8 months ago
I realised that the
mockValuesandmockMetadataobjects were not properly tree-shaken in consumer applications of@h5web/libor@h5web/app(at least with ones using Vite as their bundler). As a result, those two giant data structures were being created on every page load of myHDF5, just to name one.Tree-shaking works better (only?) with functions, so the idea is to turn
mockValuesandmockMetadatainto functions. This has benefits even in projects that do need these two structures (e.g. in the demo project), since it means that we can generate them lazily, when they are actually needed (e.g. when navigating to the mock demo).I had tried to generate the mock metadata and values lazily before, but never really got to a point that I found satisfactory. The API to access or generate entities and arrays that we use in our Jest test suites and in the Storybook was always quite convoluted.
This time, I had the idea of generating ndarrays instead of plain, nested JS arrays in
mockValues, which unlocked a lot of things, thanks to the simple fact that ndarrays store the shape of their underlying arrays. For instance, this means that we:[20, 41]...) when we generate the mock metadata;Additionally, since the internal array inside an ndarray is already flattened, we no longer need to deal with this in
MockApi.The PR is huge particularly because I took the opportunity to clean the metadata a bit and to shorten the metadata utility functions to make the whole thing a bit more readable.