All geek questions in one place

Trunk-Association vs. Backbone-Relational

I was looking for information on how we can build relationships in Backbone and came across the following two nice plugins:

Both seem to have existed for more than two years and seem to be stable. However, Backbone-relational outshines Backbone-associations in the following terms:

  • Providing almost all relationships such as one-to-one, one-to-many, many-to-one , as in a database
  • Good documentation (similar to Backbone.js ) at first glance

Since I did not have time to go through both plugins widely, I would like to know the following things from an experienced person:

  • Do both AMD support (e.g. Requirejs )?
  • How easy is it to use a plug-in with a back-end server like Ruby on Rails?
  • How easy is polymorphic relationships?
+6
source share
3 answers

The biggest difference is that Backbone-relational phobias create multiple instances of the same model with identical identifiers. Consider:

 let Person = Backbone.RelationalModel.extend({ relations: [ type: Backbone.HasMany, key: 'likes_movies', relatedModel: 'Movie' ] }); let peter = new Person({ likes_movies: [{id: 1, title: 'Fargo'}, {id: 2, title: 'Adams Family'}] ); let john = new Person({ likes_movies: [{id: 1, title: 'Fargo'}, {id: 2, title: 'Adams Family'}] ); // Change title of one of Peter movies peter.get('likes_movies').get(1).set('title', 'Fargo 2 (Sequel)'); // John corresponding movie will have changed its name console.log(john.get('likes_movies').get(1)); // Fargo 2 (Sequel)

If rewritten for Backbone-associations , the title of the film for John would not change. This can be seen as a function or a flaw, depending on how you look at it.

In addition, both libraries are very similar, except that the development of Backbone-associations seems to have stopped almost a year ago.

+2
source

In fact, based on both GitHub pulses (an activity indicator), a baseline-bound community seems much more active.

+1
source

I studied both of these libraries when I was looking for something like EmberData or Restangular for Backbone.

Both of these libraries try to compensate for the underlying weakness of magic: handle the Rest API Restful Resources correctly.
In fact, Backbone facilitates the creation of new models every time they need to be visualized (instead of reusing the instance used for another rendering elsewhere in the application).
Some inconsistencies occur when some model updates are not distributed throughout the web application.
Then, a cache of the trunk model instances is required. Backbone Relational provides such a cache, but the Backbone Association does not.

In addition, both of them redefined the Backbone code methods (set, get, reset, trigger), so they are closely related to Backbone.
This can complicate the migration of the Backbone library, especially if you use a different MVC structure on top of the Backbone (Marionnette, Thorax, Chaplin, ...)

Backbone association is easier than Backbone Relational in terms of lines of code (800 vs. 2000).

  • The implementation of the Backbone Association is easier to debug because it directly manages relationships in overloaded methods (set, get, ...)
  • In contrast, Backbone Relational relies on queues to synchronize relationship content with its internal repository. This makes debugging difficult ...

Another easy (but less used) alternative is "Backbone SuperModel": http://pathable.imtqy.com/supermodel/

  • This library combines 800 lines of code that are easier to understand than Backbone Relational (I myself was able to fix a small error).
  • It offers a basic cache instance based on the Backbone Collection.

On my side,

  • I managed to integrate the latter with RequireJs
  • I manage some polymorphic associations with him
  • A protocol has appeared between my web application and my Java base.
  • I need to update Backbone and Marionette every time I need
0
source

Source: https://habr.com/ru/post/973688/

More articles:


All Articles