Blaze doesn't have the problem Blaze+ attempts to solve (repo provided)

[faceyspacey]

@arunoda , ive been trying to prove there was in fact a problem with Blaze's default behavior for the better part of an hour and I can't. Blaze doesn't have the problem Blaze+ attempts to solve.

Here's my repo: https://github.com/ultimatejs/blaze-plus-test-for-arunoda ...Examine test.js and set Session.set('name', 'whoami') and watch the rendered callbacks not logging in the console. And also do the thing you did where you manually change the DOM in the Elements tab of inspector. Whatever you enter remains.

[arunoda]

This is not the case for that. I'm saying about when you pass data #with. For an example, router params via top to bottom. (Works with Dynamic.Template as well)

Then this is an issue. For an example, if one query param changed, whole UI get re-rendered again.

[faceyspacey]

I've just tested like this:

<template name="TestContainer">
  <div>
    {{#with getUser}}
      {{> Test}}
    {{/with}}
  </div>
</template>

<template name="Test">
  <span>Test Hello,</span> 
  <span>{{getName}}</span>
</template>

and again the issue doesn't exist. I can edit the Test Hello span in the Elements tab and log results from onRendered for the Test template, and it definitely doesn't re-render.

Maybe Blaze made a small optimization since you released this in September. I don't know what to tell ya. I updated the repo to reflect the #with test:

https://github.com/ultimatejs/blaze-plus-test-for-arunoda

[faceyspacey]

ps. im workin on a project to discover the precise differences between React and Blaze. The funny thing is: the deeper I've gone, the less differences I've found. The main difference is the pattern by which we develop and which is advocated by the given framework. You can basically manage state exactly like in React but in Blaze. Just, nobody does. React guides you into thinking of your components as parameterized; whereas Blaze's implicit data contexts has developers taking for granted where their data is coming from, which leads to them not parameterizing their components (i.e. as a data contexts, aka "props"), which in turn makes it so in the future it's hard to trace the data flow.

There's more, but the bottom line is that the "flow behavior" most credited toward React can easily be accomplished with Blaze. And without performance penalties--unless there is something I'm missing about Blaze+. Basically, based on the tests presented, the "anti-pattern" of passing props doesnt have the performance penalties mentioned; not anymore at least; or at least not for 99% of all use cases. If I'm wrong please let me know; i need to figure this out.

[arunoda]

Okay. Let me help you to create a case. I will update the repo with a PR.
On 2015 දෙසැ 11, සිකු at පෙ.ව. 7.12 James Gillmore notifications@github.com
wrote:

ps. im workin on a project to discover the precise differences between
React and Blaze. The funny thing is: the deeper I've gone, the less
differences I've found. The main difference is the pattern by which we
develop and which is advocated by the given framework. You can basically
manage state exactly like in React but in Blaze. Just, nobody does. React
guides you into thinking of your components as parameterized; whereas
Blaze's implicit data contexts has developers taking for granted where
their data is coming from, which makes it so in the future it's hard to
trace the data flow.

There's more, but the bottom line is that the "flow behavior" most
credited toward React can easily be accomplished with Blaze. And without
performance penalties--unless there is something I'm missing about Blaze+.
Basically, based on the tests presented, the "anti-pattern" of passing
props doesnt have the performance penalties mentioned; not anymore at
least; or at least not for 99% of all use cases. If I'm wrong please let me
know precisely; i need to figure this out.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[tvogels]

I also cannot reproduce the problem in Blaze.