Skip to content
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

vm.js logic? #18

Open
chchrist opened this issue Apr 25, 2012 · 5 comments
Open

vm.js logic? #18

chchrist opened this issue Apr 25, 2012 · 5 comments

Comments

@chchrist
Copy link

Hello,
Thnx for the great boilerplate. I am trying to understand the logic in vm.js. Specifically the cleanup procedure. It seems that it checks if the view is not undefined then does a cleanup. But that way, you clean the same view you create later. You have to clean/unbind events etc the view the user was before and then create the new view.

Is it correct or am I missing something?

Thanks :)

@thomasdavis
Copy link
Owner

So if you create a view called 'SomeViewLabel' and then try create another view with the name 'SomeViewLabel' what will happen is that the first one you created will unbind any events attached to it before it overrides itself with the new one.

Does this make any sense?

@chchrist
Copy link
Author

Ah OK , yes it makes sense, but what would be great is to be able to be at viewone and when you go to viewtwo to unbind the events or other stuff from viewone. Let's say my viewone has a var tick = setInterval() I want to be able to cleatInterval(tick) before I open the viewtwo.

@hansgill
Copy link

Hi thomas,

trying to understand why we would want to keep the views around and then remove them when we are about to create a new view with the same name? Wouldn't it make more sense to follow the path you outline in your tutorials (remove the currentView if there is one and then set the currentView to the new view being displayed) ?

Appreciate your feedback and thoughts.

@joaovpmamede
Copy link

Shouldn't the "vm" be responsible for calling the "destroy"(unbind and remove view) method on each view that is about to be replaced?
Not sure if you want to have previous created views being "zombies" around your application.

@arunkjn
Copy link

arunkjn commented Jul 18, 2013

I agree with @chchrist. vm should also have a separate destroy logic(along with create), where a view can be explicitly destroyed by passing its name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants