What's so cool about React? Am I obsoleting myself by not learning it?

[sashko]

No he’s actually correct, blaze will only update one element if a single item changes in a long cursor.

[jedwards]

I may be wrong, but I don’t think it’s creating 100 React elements in a virtual DOM. I believe it uses keys (<li key={someUniqueId}>) to modify innerHTML and add/remove as many LI tags as needed. So if you had 100 list items, and you changed a single element, it does a key look-up to grab the position, and simply does a chosenLI.innerHTML = ‘new text’.

So if you do the following:

console.log(JSON.stringify(<ul><li>hello</li><li>world</li></ul>, null, "  "));

It prints out this:

{
  "type": "ul",
  "key": null,
  "ref": null,
  "_owner": null,
  "_context": {},
  "_store": {
    "props": {
      "children": [
        {
          "type": "li",
          "key": null,
          "ref": null,
          "_owner": null,
          "_context": {},
          "_store": {
            "props": {
              "children": "hello"
            },
            "originalProps": {
              "children": "hello"
            }
          }
        },
        {
          "type": "li",
          "key": null,
          "ref": null,
          "_owner": null,
          "_context": {},
          "_store": {
            "props": {
              "children": "world"
            },
            "originalProps": {
              "children": "world"
            }
          }
        }
      ]
    },
    "originalProps": {
      "children": [
        {
          "type": "li",
          "key": null,
          "ref": null,
          "_owner": null,
          "_context": {},
          "_store": {
            "props": {
              "children": "hello"
            },
            "originalProps": {
              "children": "hello"
            }
          }
        },
        {
          "type": "li",
          "key": null,
          "ref": null,
          "_owner": null,
          "_context": {},
          "_store": {
            "props": {
              "children": "world"
            },
            "originalProps": {
              "children": "world"
            }
          }
        }
      ]
    }
  }
}

This is a React Element. It is separate from any React Component instance, which represents what’s currently in the DOM. If a React Component’s render() returns this React Element, the React Element is compared with the current state of the React Component to determine what needs to be updated. Then the real DOM is updated accordingly.

So if you return a <ul> containing 100 <li> tags in render() it does create 1 parent React Element with 100 child React Elements and compares them all with the React Component tree.

[manuel]

blaze will only update one element if a single item changes in a long cursor.

In his posts he assumes the opposite and “hopes” blaze would only update 1 element at a time. So he’s arguing based on wrong assumptions. That’s why he’s wrong.

[jedwards]

No he’s actually correct, blaze will only update one element if a single item changes in a long cursor.

That’s good to know, when I was more worried about performance I was almost tempted to stick with pure Blaze for this reason, though luckily I haven’t run into any performance issues with React.

[Steve]

@jonlachlan

I think this covers the only real pain point with using Blaze. I sometimes avoid creating sub-templates only because child templates can’t inherit reactive helpers (so far as I can tell). Is there any discussion/roadmap to address this?

See here:
https://meteor.hackpad.com/Proposal-for-Blaze-2-bRAxvfDzCVv

[shock]

Another step towards React Maintainability ?
http://blogs.msdn.com/b/typescript/archive/2015/09/16/announcing-typescript-1-6.aspx

And some link for webpack boilerplate non-Meteor. Seems TS compile errors are not reaching browser error screen yet. https://github.com/plisy/typescript-react-transform-boilerplate

[vjau]

JSX support in Typescript is cool, you can define an interface for each component props so that you are warned when the parent is not passing the correct props. Also you can define an interface for state so that each this.state members are correctly accessed.
However, AFAIK meteor own this.data interface definition is not implemented and i don’t know if it can be done easily.