Hi!
Some of my users’ data consists of relatively large, multi-dimensional (up to 6-D) numerical arrays. I wrote something akin to a rudimentary OLAP engine to allow users to display and edit it in arbitrary ways. These arrays of arrays … of arrays are stored – where else! – as a subfield in their Mongo documents.
(You might call me crazy for even attempting this kind of thing in JS, but Meteor’s latency compensation actually makes everything feel perfectly snappy.)
I’d now like to introduce reactivity, such that changes to elements of those arrays result in updated aggregates elsewhere. While I can create an observeChanges or autoRun hook on the subfield itself (the one containing the nested arrays), I can never find out which particular element was edited. As a result, I need to re-run the aggregation loops over the entire data structure every time, although most of the time that’s pretty wasteful.
This seems to be a symptom of arrays being second-class citizens in Mongo and Minimongo — index-based operations on them are a PITA, and reactivity doesn’t extend to them at all. (I do understand that there are good reasons for this.)
I’m considering diving into the Minimongo source to make this kind of thing possible at least on the client side (where it matters), but I’m afraid of sinking a lot of time into something that won’t work. Are there packages that can help me out here? If not, and I do decide to fork Minimongo, do I stand a chance of implementing element-wise reactivity at all, or are there significant architectural or performance barriers that would prevent me from doing so? Or is all of this premature optimization, and I should just shrug it off altogether? Or, alternatively, I could ditch Meteor’s reactivity and use custom events instead; is that a wiser alternative?
A penny for your thoughts!
Cheers,
Sebastian