StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><strong>When to use <code>model.get(property)</code> and <code>model.set(...)</code></strong></p> <p>You should use <code>get</code> and <code>set</code> to access the model's <em>data</em>. This means any attributes that are part of the model's serialized representation that is retrieved using <code>fetch</code> and persisted using <code>save</code>.</p> <p><strong>When to use <code>model.attributes.property</code></strong></p> <p>Never.</p> <p>You should always use <code>get</code>, and especially <code>set</code>, instead of accessing the <code>model.attributes</code> object directly, although I've seen conflicting opinions about this. I believe there is a contract between a <code>model</code> and it's consumers, which guarantees that the consumer can be notified of any changes to the model's data using the <code>change</code> event. If you modify the internal attributes object directly, events are not sent and this contract is broken. Backbone events are <em>very</em> fast, especially if you don't have any listeners attached to them, and it's not a point that benefits from over-optimization on your part.</p> <p>Although accessing the attributes directly instead of <code>get</code> is quite harmless on it's own, it should be avoided so the <code>attributes</code> object can be considered totally, completely private. </p> <p>If you absolutely need to prevent some change triggering events, you can use the <code>silent:true</code> option: <code>model.set({key:val}, {silent:true})</code>. This does break the aforementioned contract, and even Backbone's own documentation gives the following caveat:</p> <blockquote> <p>Note that this is rarely, perhaps even never, a good idea. Passing through a specific flag in the options for your event callback to look at, and choose to ignore, will usually work out better.</p> </blockquote> <p><strong>When to use <code>model.property</code></strong></p> <p>Any properties which are <em>not data</em>, i.e. temporary state variables, calculated properties etc. can be attached directly to the model entity. These properties should be considered temporary and transitive: they can be recreated upon model initialization or during its lifetime, but they should not be persisted, whether public or private. A typical naming convention is to prefix private properties with the <code>_</code> character as follows:</p> <pre><code>this._privateProperty = 'foo'; this.publicProperty = 'bar'; </code></pre>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload