MeteorJS collection vs. array

I am creating an application using MeteorJS that allows users to create items (e.g, text, images) and to collaboratively spatially organize these on a canvas. Multiple canvases can be created. In the future, items may be reused in or copied between (I am unsure yet) multiple canvases. I have never designed a collaborative (or even database driven) application before.

I could not find the possibility to create nested MeteorJS collections, and I am unsure about the (dis)advantages (e.g. considering scalability, speed) of using multiple collections vs. using an array of objects inside a collection, so I wonder what a good design pattern would be:

A:

Collection Canvases {
    Canvas {
        Array Items;
    }
    Canvas {
        Array Items;
    }
}

B:

Collection Items {
    Item {
       _id
    }
    Item {
       _id
    }
}

Collection Canvases {
    Canvas {
        Array ItemIDs;
    }
    Canvas {
        Array ItemIDs;
    }
}

Or perhaps something different?

Since Meteor "identifies changes based on the fields of the MongoDB document. But ... does not support nested fields and arrays", I'd use some data structure like you suggested in your proposal B: two collections. This ensures that only new/ updated items get pushed out to clients and not all items of a canvas.

Then make the relation between Canvas and Items as saimeunt pointed out in his comment above: Canvas{_id:"xxx"} Item{_id:"xxx",canvasId:"xxx"}. (I'm using a similar approach in my project minutocash which works fine.)

Furthermore, you can publish all related items of a canvas with the publish-with-relations package as David Weldon pointed out in this answer to a question of mine, about an issue which you might run into later with this data structure.