Skip to main content

@zarrita/storage build issue

· 3 min read

While copying Vitessce code across, I had initially disabled use of ZipFileStore because I had a memory of it being problematic for me in earlier prototypes - and marked 'experimental' in the zarrita documentation.

At some point I thought that I was satisfied it was in fact working ok - but now I notice that there is in fact a related issues showing up, even without ZipFileStore, but perhaps more generally with '@zarrita/storage'?

How minimal should the core dependencies be?

· 4 min read

Given that the idea is to have something analogous to the Python library, that would mean that each type of SpatialElement would return something somewhat equivalent to the corresponding library in Python - to characterise the dependencies of that package as 'minimalist', even without the batteries-included [extras], seems disingenious... Perhaps the philosophy is not so much that these will be minimal, but they should avoid needless bloat and especially any likelihood of tricky conflicts to manage (<cough>deck.gl</cough>).

Initial Design Notes

· 6 min read

This project is a TypeScript implementation of the SpatialData library.

It is a collaborative effort by the Taylor CCB Group at the Center for Human Genetics, Oxford University and the Gihlenborg Group at the Harvard Medical School - Department of Biomedical Informatics.

sketch

· One min read

Using MDX format to render a react component that will respond to HMR as we edit the code to start doing something useful.

Transformations, attrs, metadata versions, testing oh my!

· 7 min read

Should consolidated metadata be considered the source of truth?

Short answer to the above question is probably "no" in the long term, and "I don't see why not, as long as we're clear that we expect stores to be treated as immutable for now". I'd welcome any feedback on my stance there.

In the meanwhile, some thoughts on breaking out of my current procrastination loop.

Notes on ported Vitessce code, TypeScript etc.

· 6 min read

A lot of the Vitessce code is written in .js files with // @ts-check and quite extensive type-annotations in jsdoc form.

While moving the code across, I've been been changing this so that it is more regular TypeScript - which has mostly been a fairly straightforward process, and I think the result is somewhat cleaner... but some of these changes are also intermingled with what should be very minor changes to functionality...