Zet - What is the subclassablemodel all about in Drains?

What is the subclassablemodel all about in Drains?

from crush analysis

In this codebase, many of your Backbone‐style models inherit from Drains.SubclassableModel, which augments the standard Backbone.Model with “subclass”-aware URL handling, saving, fetching and destroying.

Drains.SubclassableModel

• It overrides the core Backbone methods (save, fetch, destroy) to inject extra behavior (e.g. global user/device IDs, local vs. remote sync, timestamp fields).
• Provides two URL helpers:
– superclassURL(): builds the base REST URL for the “superclass” table (e.g. /api/<table>[/id]).
– subclassURL(): same but for subclass storage—appends _structured for Asset subclasses.
• Defines fetchAsSubclass(): calls fetch with url set to subclassUrlBase(), flags the model as “fetchedAsSubclass,” and preserves user-supplied success/error callbacks.
• Defines saveAsSubclass() and upload() to save with the subclass URL plus upload flag.

subclassUrlBase

• This is a thin wrapper around subclassURL, but spelled in camelCase in the code.
• By default, subclassUrlBase returns exactly the same string as subclassURL():

const suffix = this instanceof Drains.Asset ? "_structured" : "";
let url = `/api/${this.table}${suffix}`;
if (!this.isNew()) url += `/${this.id}`;
return url;

• Many models simply inherit this; Assets override subclassUrlBase to include additional path segments or query parameters for structured downloads.

Like junction was doing with include_location_metadata until we moved to location_metadata on the asset level field

In practice

Whenever you call model.fetchAsSubclass(), model.destroy(), or model.saveAsSubclass(), the URL used on the HTTP request will be whatever subclassUrlBase() returns, ensuring you hit the appropriate subclass endpoint on your REST API rather than the generic superclass path. This pattern lets you cleanly store and retrieve both base records and any polymorphic subclass data without duplicating the core model logic.

#drains