New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collection.update() delete&recreate the template instance instead of just rerender it #724

Closed
acemtp opened this Issue Feb 22, 2013 · 1 comment

Comments

Projects
None yet
2 participants
@acemtp

acemtp commented Feb 22, 2013

Collection.update() delete&recreate the template instance instead of just rerender it.

To reproduce this bug, follow the instruction (don't pay attention to the repo name, there's no constant in the code):

git clone git://github.com/acemtp/meteor-constant-bug.git
cd meteor-constant-bug/
./meteor

Open the browser console, you'll see that when you click the first time on the button, the template is destroyed and created again. if you click a second time, it's not destroyed/created anymore, just rerendered (as expected).

About the created(), the doc says that "This callback is called when an invocation of myTemplate represents a new occurrence of the template and not a re-rendering of an existing template instance."

In the example, it's a re-rendering of an existing template instance.

The very strange thing is that if you remove the {{#if blockLoading}} and just keep the {{>blocks}} then it works as expected in the doc so it seems to be related to the reactive session in blockLoading helper.

As @avital and @dgreensp said in https://groups.google.com/forum/?fromgroups=#!topic/meteor-talk/LKeoSkYqrYE

It seems to be a bug so I fill this issue :-)

dgreensp added a commit that referenced this issue Feb 22, 2013

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Feb 22, 2013

Fixed on devel. It was a logic bug in the automatic labeling of templates for matching purposes.

Thanks for the great small reproduction. It allowed me to track down the problem, and I used it as the basis for a unit test.

@dgreensp dgreensp closed this Feb 22, 2013

martijnwalraven pushed a commit that referenced this issue Feb 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment