What do you **really** know about rendering? (Blaze, React)


#1

Reactive Cursor = Posts.find();
Reactive Array = Posts.find().fetch();

##Blaze Rendering: Iterating over Reactive Arrays with {{#each}}

  • a small change in a single reactive array element causes all DOM nodes of all array elements to rerender
  • a small change in a single reactive array element causes only the corresponding DOM node to rerender.

0 voters

##Blaze Rendering: Iterating over Reactive Cursors with {{#each}}

  • a small change in a single reactive cursor element causes all DOM nodes of all elements to rerender
  • a small change in a single reactive cursor element causes only the corresponding DOM node to rerender.

0 voters

##React Rendering: Forcing .fetch() when getting reactive cursor data.

Assume parent component owns the reactive array and subscription, and a list of children of the parent are generated based on the array.

  • a small change in a single array element will cause all DOM nodes of all array elements to rerender
  • a small change in a single array element will cause only the corresponding DOM node to rerender

0 voters

##React Rendering: Passing cursors, not arrays, between components (not using .fetch()).

  • React does not allow this functionality
  • Actually, it does, and I will reply to this thread on how it is possible.

0 voters


#2

This is cool, I hope more people vote. The truth is, there are so many steps happening between the data update and eventual updating of the (real) DOM, and both frameworks do this so differently, that it’s easy to get tripped up. But understanding what’s actually going on behind the scenes can help you make huge performance gains in rendering.


#3

I’ve been learning React and I’ve got to say, never has my project been
more organized and well structured.

Unfortunately, in my time working with React, I am skeptical in its
performance over Blaze. It looks like a lot of unnecessary function calls
happen under the hood in react. If you’ve ever used Iron Router, that’s
what it feels like – “Why is my code running a kajillion times?”. I could
always debug and solve this with Blaze.

I really hope MDG can create some sort of “best practices” guide for using
React with Meteor. At this point, I think it’s very easy to fall into
writing shitty code with React.

For example, where should containers be placed in the hierarchy? Is React
smart enough that they could be placed at top level? Or, should one place
duplicate containers at every low level component which needs that data?
It’s not immediately clear which is more performant.


#4

Sorry, I’m on mobile so here’s an elaboration on my post:

Say you need a user’s score, picture, and email. Assume that these fields
are highly dynamic. Suppose that there’s an Email component, Score
component, and Picture component, all children of the User component.

Would it be best to run this: Meteor.users.findOne(myId, allThreeFields)
in the User component, and then trickle down only the necessary data via
props? Or, would it be more performant to run three finer grained queries
at each of the children components? For example:
Meteor.users.findOne(myId, onlyEmailField) in the Email component, and
similarly for the other two children components.

It’s not clear which would perform better. React would have to diff all of
the components when the full query of the User changes in the first
scenario, but you’re also using less observers.

@sashko, did MDG come up with a best practices which address this? Have
tests already been run?