Open faceyspacey opened 8 years ago
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.
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:
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.
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 https://github.com/kadirahq/blaze-plus/issues/7#issuecomment-163807142.
I also cannot reproduce the problem in Blaze.
@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.