Reputation: 4081
Background: I'm using Backbone for the first time. In my project, I have one "main" model - let's call it Customer
. At all times, only one Customer
is displayed. I have a CustomerList
Collection, which queues the Customer
s. At a button click, the next Customer
is displayed. CustomerView
does all the rendering etc.
The problem: should I make a new instance of CustomerView
every time we switch to the next Customer
? Another possibility (which I started out with) was just one instance of the View and passing the model to the render function of the view (view.render(model)
). This way, I can get the next Customer
from the List
, pass it on to the render function of the view and that's it. I'm wondering though how well this suits the MVC pattern of Backbone? It would seem more "standard" to get the new model, kill the current View and make a new View instance.
Any suggestions from experienced Backbone developers, please? Thanks.
Upvotes: 1
Views: 37
Reputation: 47956
If the only thing that is changing is the actual model then you should definitely keep your CustomerView
around and simply provide it a new model to display.
This most certainly pertains to MVC concepts of functional separation. The CustomerView
only needs the relevant data (supplied by the model) in order to perform it's task of rendering the view.
Think of it like this - is there any need to reset your CustomerView
module? It shouldn't hold and model specific information at all so essentially it shouldn't care that you change the model - only that it needs to be re-rendered once the data changes.
The one instance where it would make sense to me to totally "kill" the current view would be if the user navigates to a different section of your application that has no relation to customers and has no option to view customer details. Only then would it make sense to completely release un-needed modules.
Upvotes: 2