Why fetch in composer?

[merlinstardust]

Why is fetch being used in the composer functions? Doesn't fetch return a non-reactive array?

Why not just return a cursor?

[arunoda]

Could you give more context to this ?

[merlinstardust]

In core/containers/postlist.js, there is this line

const posts = Collections.Posts.find().fetch();

[arunoda]

That's the way we do it. We called .find() here. So, whenever there's a change inside to the collection, you'll get data.

[merlinstardust]

But why not just do it without the fetch?

const posts = Collections.Posts.find();

To me, it seems like fetch would become inefficient for large sets of data because it's returning all the data at once.

[arunoda]

This is not possible with React. This is only something works in Blaze. Have you done a performance test? Usually this won't be an issue in React.

[newswim]

Fetch assigns dependencies and is in fact reactive. From the docs:

Cursors are a reactive data source. On the client, the first time you retrieve a cursor’s documents with fetch, map, or forEach inside a reactive computation (eg, a template or autorun), Meteor will register a dependency on the underlying data. Any change to the collection that changes the documents in a cursor will trigger a recomputation. To disable this behavior, pass {reactive: false} as an option to find.