Backbone.js – What is the best approach for global/shared/related models?

Asked By: Anonymous

I’m currently building an application using Backbone.js with a number of different models that all relate to each other in various ways. I’m currently experimenting with various architectural approaches.

In a nutshell the model relationships looks something like this:

Workspace > Projects > Tasks

There are a few other models, such as lists and categories, that are attached to a project.

On a page with a task list, I’m dumping the JSON of the tasks onto the page and filling up the collection. This works ok, but at the moment all tasks are pulling in their own project data.

task.project.id
task.project.name

The projects are also being pulled in various other locations on the page for various lists. Tasks can also be part of a List which is assigned to a Project. This means I’m also making requests to pull in the lists for a project in various places as well.

The main problem with this is that when updating a model in place I need to find some way to ‘sync’ them. Which is crazy. They should all be using the same model instance so that each view is using the same model and is updated accordingly without having to do anything.

I’ve been researching various Backbone.js architectural designs to try and find the answer. Chaplin (https://github.com/moviepilot/chaplin), for example, uses a mediator object to pass data between views. Using this approach, I could have a Projects collection on the mediator and pass this around to the various views via the mediator object.

Each project would include all of it’s lists, categories, assigned users etc. Then I could request for a project model like so:

App.Projects.get(12)

Then the task would just need the project ID and a getter and setter method. Views could get access to available projects, project lists, project users easily as well without relying on digging into the model or making further AJAX calls. Additionally, the task models wouldn’t require any of the project data on them.

However, dumping all this data in a global object seems bad.

I would possibly end up with something like this:

App.Workspaces
App.Workspaces.get(1)
App.Projects
App.Projects.get(12).get('lists')[0]
App.Projects.get(12).get('users')

To use like this:

var projectId = model.get('project')
var project = App.Projects.get(projectId)

Or with a getter method:

var project = model.getProject()

And add the mediator as a dependency at the model level instead.

Adding a large global object like this adds a fairly large dependency that could make testing difficult. It also seems wrong to assume that the mediator will even have the project available. Maybe it could make the model, fetch it and return it if it doesn’t exist.

Any help here would be great! I’d love to know how other people have solved this problem.


Solution

Answered By: Anonymous

I recommend to have a common Collection for all your Task Models. Kind of cache.

Something like: App.Store.Tasks.

Any time you need to feed the Poject.Tasks look first in the App.Store.Tasks and then:

A. If you found the Task there then take it and add it to your Project.Tasks.

B. If not found there then create, fetch and add it to both: App.Store.Tasks and your Project.Tasks.

This way other Project that tries to fetch a Task that already exits will do the same and they both will share the same Model.

Any time you modify one of your Task models in a Project you’ll be modifying this Task in every other Project.

techinplanet staff

techinplanet staff


Windows 10 Kaufen Windows 10 Pro Office 2019 Kaufen Office 365 Lizenz Windows 10 Home Lizenz Office 2019 Home Business Kaufen windows office 365 satın al follower kaufen instagram follower kaufen porno