All examples suggest to use .fetch() on collections, which is not reactive from what does meteor guide say. wondering how does that work and isnt there a bottleneck happening?
Why do you think fetch won’t be reactive? In both Blaze and React fetch is reactive. The reason your use a cursor with {{#each}} in Blaze is because it makes rendering more efficient. This isn’t an issue in React since if uses virtual DOM diff-ing to render changes.
ok. here’s the part in docs that confuses me:
When you want to retrieve the current list of documents from a cursor, call the cursor’s .fetch() method:
// get an array of posts
var postsArray = Posts.find().fetch();
Keep in mind that while the computation in which you call fetch will rerun when the data changes, the resulting array will not be reactive if it is passed somewhere else.
Right so all it does is return an array. The array itself is not reactive, it is just an array. But that doesn’t mean that the function that made the db query isn’t reactive. So in Blaze a helper is the reactive part, if you use a reactive source, like collection.find().fetch() it will still rerun whenever the result of that query changes. But if you use the array somewhere else that will no be reactive, whereas if you pass just collection.find() to another helper it will be.
In terms of react the getMeteorData() function is reactive, so any access to a reactive data source will cause that function to rerun. It is much simpler than the normal react model of doing setState() since it will automatically update the component state when the data sources change.
the idea was isnt passing the full array of records slower than passing a cursor?
In Blaze this is true, because it handles DOM updates through dependency tracking using a cursor ensures that Blaze can update only the rows/elements in an query that have changed, which is why it is faster over fetch since with Blaze if you use fetch instead of a query it will re-render the entire array every time any element changes.
React on the otherhand does things completely differently. Instead of keeping track of which parts of the DOM change it instead keeps a virtual DOM. This virtual DOM is what you are actually modifying when the array changes due to a Meteor computation rerun. Mutating the vDOM is computationally cheap. What React does under hood is every time the vDOM gets mutated, the old vDOM and new vDOM are diff-ed and the changes that it gets from this operation are the minimum amount of operations needed to update the real DOM, which it does through what is called a patch operation.
As a general rule with React, unless you are dealing with thousands of components or huge arrays, you don’t really need to worry about the performance cost of changing the state of a component. React is usually fast enough for the majority of cases. (Note if you do end up getting bad performance, there are things you can do to improve that, but this response in already very long).
Blaze calls .fetch() in {{#each}} behind the scene anyway, but it tryes to render changes only. Using React you can send full array - it is fast. JS is fast, but DOM is slow. So DOM updates makes Blaze slow. React works with virtual DOM and it is faster even than Blaze’s incremental DOM updates