Backbone: バックボーンおよびES6クラス

ええ、これは間違いなく残念です。 レッグワークをしてくれてありがとう。

話の教訓は、少なくとも静的プロパティのサポートが開始されるまで、BackboneでES6クラスを使用しないことだと思います。 あなたが提案したフォールバックオプションのうち、私の好ましい解決策は、文字列/オブジェクトを戻り値として定義することです。 BackboneのAPI設計の重要な部分は、これらのプロトタイプ共有文字列とオブジェクトにあり、開発者がコンストラクターのインスタンスに各プロパティを割り当てるように要求することはAPIを汚します（メモリを浪費することは言うまでもありません）。

一貫性は別として、 extend超えるBackboneでclassキーワードを使用する理由はありますか？

素晴らしいブログ投稿。 ES6クラスとバックボーンクラスがどのように連携するのか疑問に思いました。 あなたの解決策について：

1. すべてのプロパティを関数として添付します：私はこれに反対しているわけではありません。 オブジェクトをプロトタイプに直接設定するほどクリーンではありませんが、プロトタイプオブジェクトを変更するときに大量のコードが発生するのを見てきました。 この方法は影響を受けません。そのため、ES6はクラスプロパティを含めないことを選択したと思います。
2. すべてのプロパティをデフォルトオプションとして渡します：これは、より古典的な言語で何かを行う方法ではありませんか？ これは上記よりもさらにクリーンな解決策ではないように感じます。
3. コンストラクターを2回実行します：Ick。

話の教訓は、少なくとも静的プロパティのサポートが開始されるまで、BackboneでES6クラスを使用しないことだと思います。

クラスプロパティでさえ、 super()呼び出しの後に

一貫性以外に、Backbone overextendでclassキーワードを使用する理由はありますか？

私はブログ投稿でこれに対処しました。 特に？ いいえ。理論的には、Backboneはコードと追加の概念を長期的に削減できますが、現実的には、ES6クラスがトランスパイルなしですべての関連ブラウザーで広くサポートされるまでには、少なくとも数年はかかります。コードの削減は次のようになります。何にも。

ただし、一貫性の側面を過小評価しないでください。 これがJavaScriptでオブジェクト指向プログラミングを行う「方法」になる場合（Ember / Angular / React / Typescript / Aureliaなどからこれが標準化されているようです）、これを使用しないバックボーンは、ライブラリに関連する追加の学習曲線になります。別のオプション。 特にジュニア開発者向け。 必ずしも変更に値するかどうかはわかりません。 しかし、それは衒学的な「小さな心のホブゴブリン」の一貫性のためだけではありません。

@ akre54と@jridgewellに同意します。「すべてのプロパティを関数としてアタッチする」アプローチが、提案されたオプションの中でおそらく最良であるということです。 FWIW、私が最初に相対的なjsの新参者としてバックボーンを学んでいたとき、私はこれらの「静的」プロパティとそれらの使用方法に少し混乱していたことを覚えています。

ES7には正しいクラスプロパティがあります。https： //gist.github.com/jeffmo/054df782c05639da2adbだと思い

ES7の提案はまさにそれであり、非常に初期のコミュニティ主導の提案です。 まったく明確ではありませんが、実際には公式仕様の一部になるでしょう。 現在の実装では、コンストラクターの実行後にプロパティがインスタンスに追加されるため、バックボーンには役立ちません。 （上記のjridgewellのリンクを参照するか、Babel 5.0.0で試してみてください）

@jridgewell私は@benmccormickの投稿のこの部分を参照していました：

React開発者は、Backboneユーザーが遭遇するのと同じプロパティ初期化子の問題に気づきました。 Reactのバージョン0.13の一部として、クラスの特別なプロパティ初期化構文をサポートしています。これは最終的に標準化される可能性があります。 このESDiscussスレッドには、それに関する詳細情報があり

たとえば、 wycatsのjs-decoratorsストローマンまたは元の（置き換えられた）ハーモニークラスの提案を参照してください。

クラスプロパティを持つゲッターを使用することをお勧めします。

class Row extends Backbone.View {
  get tagName() { return 'li'; }
}

絶対的な最後の手段として、たとえばヘルパーを使って静的な小道具をチェックすることができます_.result ：

_.instOrStaticVar = function(instance, property) {
  if (instance == null) return void 0;
  var value = instance[property] || instance.constructor[property];
  return _.isFunction(value) ? value.call(instance) : value;
}

うん、でも：

残念ながら、そのバージョンでは、スーパークラスコンストラクターの実行後にインスタンス化されるものとしてクラスプロパティが定義されているため、ここでのBackboneの問題は解決されません。

したがって、ES5は次のようになります。

// ES6
class View extends Backbone.View {
  tagName = 'li';

  constructor() {
    // Do anything that doesn't touch `this`
    super();
    // Do anything that touches `this`
  }
}

// ES5
function View() {
  // Do anything that doesn't touch `this`
  Backbone.View.apply(this, arguments);

  // Add class properties
  this.tagName = 'li';

  // Do anything that touches `this`
}
View.prototype = _.create(Backbone.View.prototype, {
  constructor: View
});

インスタンス変数を設定するための変更を取得する前に、要素は引き続き構築されます。

たとえば、wycatsのjs-decoratorsストローマンを参照してください...

デコレータがどのように適用されるか説明できますか？

クラスプロパティを持つゲッターを使用することをお勧めします。

：+1:。 すべてのプロパティを関数としてます。 私たちが現在持っているものほどきれいではありませんが、完全に受け入れられ、突然変異の証拠です。

絶対的な最後の手段として、たとえばヘルパーを使って静的な小道具をチェックすることができます。

それは面白いかもしれません...

あなたができること：

class MyView extends Backbone.View {
  constructor() {
    super({ tagName: 'h1' });
    this.el.textContent = 'Hello World';
  }
}

@thejameskyleこれは、すべてのプロパティをデフォルトオプションとしてスーパークラスコンストラクターオプションに

super()に依存してクラスを設定する代わりに、 init()関数などを使用することもできます。

class DocumentRow extends Backbone.View {

    constructor() {
        super();
        this.tagName =  "li";
        this.className = "document-row";
        this.events = {
            "click .icon":          "open",
            "click .button.edit":   "openEditDialog",
            "click .button.delete": "destroy"
        };
        this.init();
    }

    initialize() {
        this.listenTo(this.model, "change", this.render);
    }

    render() {
        //...
    }
}

@milesjうーん？ それは最終的なES6クラスの仕様ですぐにエラーになります

派生クラスでは、これを使用する前にsuper（）を呼び出す必要があります

それが機能したとしても、実際にBackboneコンストラクターを呼び出すことはなく、その初期化コードを取得することはありません。

私の最初の投稿からのこのリンクを参照してください： http ：

@milesj ：問題は、 this.tagNameなどを設定する前にsuper()を呼び出す必要があるということです。 また、ビューのコンストラクターで要素をthis.tagName設定する前に、すでに要素を作成しています。

@milesjは、サブクラス化するときはまだ許可されていません。

@jridgewellああ、すみません、私はそれを逃しました。 それは最も自然な選択肢のようです。 私はこれについてjeffmoとsebmckに話しました。

皆さんに裏話を与えるために、理由は、ネイティブ型（つまり配列）の拡張をサポートするために、 super()メソッドを呼び出すまでthisが決定されないためです。 そうしないと、DOM（およびおそらく他の場所）で初期化の問題が発生します。

@jridgewell @thejameskyle次に、最初にsuper（）を呼び出すだけです（更新された例）。 ES6クラスでも同じことをしたので、ここでは問題は発生しません。 ビューコンストラクタロジックをinit()メソッドに移動するだけです。

それはです多く、非常に高価な二回実行するコード。

@milesj元のブログ投稿を読みましたか？ スーパーファーストで実行すると、プロパティが処理されません。 詳細な説明については、こちらをご覧ください： http ：

はい、私はそれを読みました、そして私はまだこれが解決策ではない理由に興味があります。 誰もがビューコンストラクターを呼び出す必要があることについて話し続けていますが、必ずしもそうとは限りません。 次のようなものが解決策ではないのはなぜですか（少し工夫されていますが）？

var View = Backbone.View = function(options) {
    this.cid = _.uniqueId('view');
    // extend()ing options is no longer needed if properties are set directly
};

View.prototype.setup = function() {
    this._ensureElement();
    this.initialize.call(this, arguments);
};

class DocumentRow extends Backbone.View {
    constructor() {
        super();
        this.tagName =  "li";
        this.className = "document-row";
        this.events = {
            "click .icon":          "open",
            "click .button.edit":   "openEditDialog",
            "click .button.delete": "destroy"
        };
        this.setup(...arguments);
    }
}

非ES6との下位互換性のために推測していますか？

その場合、コンストラクターが#setup呼び出すことはないため、デフォルトのViewクラスは機能しません。 また、サブクラスの呼び出しをsuper()以外に強制すると、非常に煩わしくなります。

これは、バックボーンだけでなく、すべてのES6クラスが対処しなければならない問題です。 BabelES7クラスのプロパティ仕様を使用して個人的に解決しました。

@milesj前述のように、ES7クラスのプロパティは、コンストラクターの最後までインスタンス化されないため、この問題を解決しません。

私はこれを行うことについてjeffmoとsebmckに話しました：

class Root {
  rootProp = 'root';
  constructor() {
    console.log('Root', this.rootProp);
    console.log('Root', this.derivedProp);
  }
}

class Derived extends Root {
  derivedProp = 'derived';
  constructor() {
    super();
    console.log('Derived', this.rootProp);
    console.log('Derived', this.derivedProp);
  }
}

脱糖：

function Root() {
  this.rootProp = 'root';
  console.log('Root', this.rootProp);
  console.log('Root', this.derivedProp);
}

function Derived() {
  super();
  this.derivedProp = 'derived';
  console.log('Derived', this.rootProp);
  console.log('Derived', this.derivedProp);
}

しかし、それでもここでの問題は修正されず、不整合が発生します。

new Derived();
// >> 'Root' 'root'
// >> 'Root' undefined
// >> 'Derived' 'root'
// >> 'Derived' 'derived'

これは、バックボーンだけでなく、すべてのES6クラスが対処しなければならない問題です。

うーん？

BabelES7クラスのプロパティ仕様を使用して個人的に解決しました。

classNameのない多くのDIV要素があります。 最後のポイントを参照してくださいhttps://github.com/jashkenas/backbone/issues/3560#issuecomment -90739676、 https://github.com/jashkenas/backbone/issues/3560#issuecomment -91601515およびHTTPSを：// githubの.com / jashkenas / backbone / issues / 3560＃issuecomment -98827719。

分かりました。 その場合は、「すべてのプロパティをデフォルトオプションとしてスーパークラスコンストラクターに渡す」オプション、または「プロパティ」メソッド（コンストラクターに影響を与えない）の作成に関する最後の行を使用することをお勧めします。

class DocumentRow extends Backbone.View {
    loadProperties() {
        return {
            tagName: 'li',
            className: 'document-row',
            events: {
                "click .icon": "open",
                "click .button.edit": "openEditDialog",
                "click .button.delete": "destroy"
            },
            foo: 'bar'
        };
    }
}

// Contrived example
var View = Backbone.View = function(options) {
    this.cid = _.uniqueId('view');
    options || (options = {});
    _.extend(this, this.loadProperties(), _.pick(options, viewOptions));
    this._ensureElement();
    this.initialize.apply(this, arguments);
};

Toolkitで同様のことを行いました。これは、 https ： 。

やあ。

ここでの議論を正しく理解していれば、バックボーン開発者は回避策とベストプラクティスについて議論していますが、この問題に対処するためにBBコアに実際に変更を加えるつもりはありませんか？ （私は彼らがそうすべきだと示唆しているわけではなく、それらの変更が何であるかについても私にはわかりません）。 言い換えれば、すべてのプロパティを関数として使用するか、ゲッターをトピックの最後の単語として使用するという提案ですか？ ありがとう。

@gotofritzすべてのプロパティをインスタンス上に強制的に存在させるES6のソリューションは拡張できないため、回避策について説明しています。 バックボーンのクラスシステムはここで正しいことをしています。

ES7クラスに静的プロトタイププロパティをいくつかの議論がありますが、これまでのところ具体的なことは何もありません。 それまでの間、Backboneのextend固執すると思います。

ありがとう。 ES6クラスをもう少し試してみます... :-)

これに遭遇した他の人の利益のために、実際には「すべてのプロパティをデフォルトオプションとしてスーパークラスコンストラクターに渡す」の方が良いと思います。たとえば、アプリには、インスタンス化時に渡す必要のある動的な（ローカライズされた）ルートがあります。また、routes（）メソッドを使用しても機能しません。 一方、以下は

class Router extends Backbone.Router {

 constructor (localizedRoutes) {
    _.defaults(localizedRoutes, {
        "nonLocalizedRouteA/": "routeA"
        "*actions": "defaultRoute"
     });
 super({ routes: localizedRoutes });
}

これを見たばかりですが、モデルが持つidAttributeプロパティでは、両方の回避策が機能しないと思います。 Backboneはmodel.idAttributeを使用してプロパティにアクセスするため、メソッドは機能しません。 また、モデルコンストラクターは、オプションとしてのプロパティの追加を完全にはサポートしていないようです。

idAttributeプロパティでは両方の回避策が機能しないと思います

すばらしいキャッチです。これに対処するPRに取り組みます。 それまでの間、getter表記を使用して、カスタムidAttribute （およびcidPrefix ）を提供できます。

class Model extends Backbone.Model {
  get idAttribute() {
    return '_id';
  }

  get cidPrefix() {
    return '__c';
  }
}

Backboneがmodel.idAttributeを使用してプロパティにアクセスするため、メソッドは機能しません

get idAttribute() { return '_id'; }はgetterメソッドであり、通常のプロパティと同じようにアクセスされます。 this.idAttribute === '_id'; 。

これは、大幅な書き直しが必要なように聞こえ始めています。 バックボーンv2はおそらく？

これは、大幅な書き直しが必要なように聞こえ始めています。 バックボーンv2はおそらく？

まったくそうではありませんが、ES6サブクラス化はすでにサポートされています（ Modelsを除く）。 誰かが@ akre54の静的プロパティの提案を調べたら面白いと思いますが、元の投稿の2つのソリューションではそれも必要ありません。

@jridgewell 、迅速な解決策に感謝します！

このスレッド（具体的にはYehuda Katzの提案）でデコレータについて言及されていましたが、それでこの問題が解決するかどうかは未解決でした。

私は提案どおりにそれらをいじっていました、そしてあなたはこのようなデコレータを書くことができます：

function props(value) {
    return function decorator(target) {
        _.extend(target.prototype, value);
    }
}

そして、私たちが使用している例は、次のように書くことができます

@props({
      tagName: 'li',
      className: 'document-row',
      events: {
        "click .icon": "open",
        "click .button.edit": "openEditDialog",
        "click .button.delete": "destroy"
      }
    })
class DocumentRow extends Backbone.View {

    initialize() {
        this.listenTo(this.model, "change", this.render);
    }

    render() {
        //...
    }
}

これは私にとってはうまくいくようです。 デコレータは、クラスコンストラクタが実行される前にクラスに適用されます。 これは単なる宣言型のことわざです

class DocumentRow extends Backbone.View {

    initialize() {
        this.listenTo(this.model, "change", this.render);
    }

    render() {
        //...
    }
}
_.extend(DocumentRow.prototype, {
      tagName: 'li',
      className: 'document-row',
      events: {
        "click .icon": "open",
        "click .button.edit": "openEditDialog",
        "click .button.delete": "destroy"
      }
})

実際、私はそれをテストしていませんが、静的プロップとプロトタイププロップの両方が必要な場合は、バックボーン拡張機能全体をデコレータにすることができます。

残念ながら、これは今のところ単なる提案ですが、バベルは実験的な旗の後ろでそれをサポートしているので、人々が冒険を感じているなら、それはここで可能な解決策です。

@benmccormick 、デコレータテクニックは私にとってうまく機能します。 これは今のところ単なる提案である以外に、このアプローチを採用することについて他の懸念はありますか？

@andrewrota私は今、このようなものをフォローアップするブログ投稿を文字通り書いています（あなたがコメントしたときにこのスレッドを読んでいました）。 それは大きな「以外」ですが、私は個人的には何も見ていません。 実際には、上記で説明したものよりもうまく機能し、デコレータを使用してBackbone用のいくつかの優れた新しいインターフェイスを作成できると思います。

私がこれについて最初に考えさせられた@StevenLangbroekからのこの要点を参照してください： https ： //gist.github.com/StevenLangbroek/6bd28d8201839434b843

これが私が投稿しているフォローアップ投稿のプレビューです： http ： 今すぐ永久リンクで更新

今週初めに永続的なURLに移動します。 しかし、このスレッドからの基本的な要約と私が学んだことは次のとおりです。

バックボーンプロパティを現在のES6クラス仕様で機能させるには3つのアプローチがあります（最初の2つは完全にサポートされていると見なされるために＃3684が必要です）。

1. コンストラクターですべてのプロパティをスーパーに渡します
2. すべてのプロパティをメソッドとして扱います
3. クラスが宣言された後、プロトタイプにプロパティを直接追加します

私はまだこれらすべてをある程度表現力を制限していると見ています。 しかし、デコレータが正式な仕様になれば、問題は多かれ少なかれ解決されると思います。 デコレータには、さらに2つのオプションがあります。

1. クラスのトップにある小道具を取り、それらをプロトタイプに追加する小道具デコレータを追加します
2. より表現力豊かできめの細かいインターフェイスを可能にする、いくつかの特別な目的のデコレータを作成します。

これらのソリューションのいずれも、＃3684以外にBackboneに追加の変更を加える必要はないと思いますが、デコレータが標準化された場合、バックボーンデコレータライブラリには興味深い役割があります。

月曜日/火曜日に投稿する前に、投稿に関するフィードバックをお待ちしています。

@benmccormick修正のおかげで、デコレータは構築が行われる前に評価されると思いました。 要旨を少し更新します。 また：ブログ投稿で言及してくれてありがとう:)あなたがそれを公開するときにツイッターで私にpingしますか？ ：+1：

マリオネットのmodelEventsとcollectionEventsに同じ構文を使用できますが、トリガーには使用できません。 それらはクラスデコレータ（ブログ投稿のtagNameやtemplateなど）を介して公開できますが、私は考えていました：これに静的プロパティを使用することはできませんか？ または、それはバックボーンでは機能しませんか？

デコレータはまだステージ0であることは理解していますが、Backboneアプリの作成方法、特にイベントハッシュよりもメソッドデコレータの優れたアップグレードになると思います。これは、うなり声よりも一気飲みを好むようなプログラミングスタイルです。

@StevenLangbroek静的プロパティの説明については、上記を参照してください。

現在指定されている構文は、プロトタイプに追加するのではなく、各インスタンスにローカルプロパティを作成します。 これらのプロパティは、スーパーコンストラクターの実行後に追加されます。

@benmccormick 、投稿は見栄えがよく、各オプションのトレードオフを説明するのに良い仕事をしていると思います。 この時点で、私は特別な目的のデコレータアプローチが本当に好きであり、デコレータが仕様に組み込まれていると仮定すると、それが最良のアプローチのようです。

@benmccormickのデコレータはプロトタイプではなくコンストラクタで_#extendを呼び出し、次に@ akre54の_.instOrStaticVarメソッドを_#result代わりに使用する必要がありますか？ それは壊滅的な変化になると思いますが、私見ではそうすればもっときれいに見えます。 @ akre54が指摘したように、そのように定義されたプロパティはプロトタイプで共有される文字列とオブジェクト（つまり、すべてのインスタンスで共有される）であるため、クラスを介してアクセスする必要があります。

私はさらに進んで、必要な方法でクラスのプロパティを機能させます。 クラスプロパティにも注釈を付けることができ、装飾されたプロパティをプロトタイプにアタッチする特別なデコレータを作成できます。

class TodoView extends Backbone.View {
  <strong i="6">@protoprop</strong>
  static tagName = 'li';
}

function protoprop(target, name, descriptor) {
  target.prototype[name] = descriptor.initializer()
}

例を示したBabelREPLを参照してください。 それは実験的なものに依存していますが、機能します。

@ just-boris私のブログのコメントで説明されているように、ここで見られる動作には、クラスプロパティとデコレータ仕様のBabelの処理の実装の詳細があります。 現在、どの提案でもその動作は定義されていません。 あなたが道というものをしたい場合は、問題にしたいでしょう、ここで、および/または、ここにクラスのプロパティ標準化された行動にデコレータを作成します。 そうでなければ、あなたがしていることはいつでも壊れる可能性があります（そしておそらくそうなるでしょう）。

@benmccormick wycats / javascript-デコレータには、プロパティ初期化子に関する追加の定義がすでにあり

ここでの主な懸念事項は、プロパティ初期化子が通常の記述子とクラスメソッドであるため、デコレータもそれらをラップできることです。 そのセクションの仕様は変更されていませんが、心配する理由はわかりません

ああ、とてもかっこいい、私はそれを見ていませんでした。 それを指摘してくれてありがとう。

11:29時月、2015年9月21日には、ボリスSerdiuk [email protected]
書きました：

@benmccormick https://github.com/benmccormick
https://github.com/wycats/javascript-decoratorsにはすでに余分なものがあります
プロパティ初期化子に関する定義
https://github.com/wycats/javascript-decorators/blob/master/INITIALIZER_INTEROP.md
。

プロパティ初期化子が通常の記述子であるという主な懸念事項は、
クラスメソッドだけでなく、デコレータもそれらをラップできます。 見えない
そのセクションの仕様は変更されていませんが、心配する理由

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/jashkenas/backbone/issues/3560#issuecomment -142015454
。

https://github.com/typhonjs/backbone-es6の使用と@benmccormickによって提案された方法の手法の長所/短所を知りたかっただけです。

ところで、すばらしいブログ投稿をありがとう@benmccormick ！

提案（＃121）プルリクエストに加えて、ここにpropertiesメソッドを実行中https://github.com/dsheiko/backbone-abstract/tree/master/demo-es6/src/Js
@ akre54が述べたように、ジャスティンはすでに同様の解決策を提案しています（ preInitializeメソッド）。 すでに私のブランチでそれを使用している間、それは本当に私にとって問題を解決します。 宣言型のクラスプロパティを禁止していないにもかかわらず、TypeScriptでも役立つように見えました。

PS preInitializeはより一般的に聞こえるので、このコンテキストではより適切です。 とはいえ、コンストラクターのすべてのジョブの前にメソッドを呼び出すと、 preConstructようになります。

プロトタイプにそれらを設定する新しいクラスプロパティの提案が表示されることを本当に望んでいます。 提案に関わっている多くの人がその影響を心配しているようですが、jeffmoの提案がそれらをコンストラクターに入れているのに対し、クラスメソッドがプロトタイプに直接アタッチされることは非常に一貫性がありません。

プロパティをプロトタイプに直接アタッチすることで、ほとんどすべてのReact / BackboneコードをES2015クラスに移行できるようになります。

素晴らしいブログ投稿@benmccormick !! 私のプロジェクトでそれらのデコレータを使用する予定です

@benmccormick 、デフォルトのプロパティでクラスを宣言する別の方法を考えました。https ：

これは、クラスをネイティブにサポートし、適切に発生し、コンストラクターまたは宣言後にクラスを定義するよりもはるかに見栄えのする環境で通常実行されます。 ES2016 / ES2017のパイプラインに登場するデコレータとクラスプロパティの提案により、これはBackboneの長期的なソリューションよりも学術的な演習になる可能性がありますが、2〜3年が長すぎる場合は、このようなものが間違いなく実行可能なオプションです。待つ。

実は、クラスプロパティはまだEcmascriptプロポーザルステージシステムのステージ1にあります。 「ユーザーが何を得るのか」という点では、それはちょっとしたことのように思われるので、理由はわかりません。 もちろん、構文的にもリファレンス実装の観点からも、内部でどのようなことが壊れるかはわかりません。

https://github.com/tc39/ecma262
https://github.com/jeffmo/es-class-fields-and-static-properties

これを読んで、 https：//github.com/epicmiller/es2015-default-class-propertiesが良いアプローチだと思います。 試してみると、Backboneにこれに対する組み込みのサポートがあることに気づきました。 例えば：

class MyModel extends Backbone.Model.extend({
   idAttribute: 'id'
}) {
   // ...
};

上記のコードは、MyModel.prototype.idAttributeを適切に設定します。 TypeScriptの場合、コンストラクター関数インターフェイスを返すように宣言ファイルを少し調整する必要がありますが、これはES6ユーザーには関係のない詳細です...

@ t-beckmannは非常に優れたソリューションです。見た目は読みやすく、変更は最小限で済みます。 ありがとう！

このスレッドは2年前に行われていることを認識していますが、Backbone＆ES6クラスを検索した場合でも、トップ（かつ唯一）の結果の1つであり、ここで何度か言及されているクラスプロパティを利用した潜在的なソリューションを共有したいと思いました。 。

クラスプロパティがステージ2にあり、babelプリセットで広く利用できるようになったので、もう一度見てみようと思いました。 前述のように、インスタンス/メンバープロパティの問題は、_after_ constructor()までプロトタイプに適用されないことですが、設定する必要のあるプロパティの多くはコンストラクター内で使用されます。 静的プロパティはすぐに適用されますが、（設計上）クラスのインスタンスにはコピーされません。

次のshimは、コンストラクターを実行する前に、静的プロパティをコンストラクターからインスタンスにコピーします（事実上、新しいコンストラクターを作成し、プロパティを適用してから、元のコンストラクターを実行します）。 それは間違いなくハックですが、私は結果にかなり満足しています：

シム：

export default function StaticShim(Ctor) {
    const NewCtor = function shim(...args) {
       Object.keys(Ctor).forEach((key) => {
            if (this[key] === undefined) {
                this[key] = toApply[key];
            }
        });

        Object.assign(this, this.constructor);

        Ctor.apply(this, args);
    };

    NewCtor.prototype = Object.create(Ctor.prototype);
    NewCtor.prototype.constructor = NewCtor;

    Object.keys(Ctor).forEach((key) => {
        if (NewCtor[key] === undefined) {
            NewCtor[key] = Ctor[key];
        }
    });

    return NewCtor;
}

そして使用法：

class TestModel extends StaticShim(Backbone.Model) {
    static idAttribute = '_id';
    static urlRoot = '/posts';

    initialize() {
        console.log(this.url()); // Correctly logs "/posts/{id}"
    }
}

それが他の誰かを助けるか、誰かがそれについて何か考えを持っている場合に備えて、ここにそれをドロップしたかっただけです。 ありがとう！

古い問題を復活させて申し訳ありません。

ES6クラス宣言をBackbone。*。extend（{...}）を使用するように変換するbabelプラグインを作成することは可能でしょうか、それとも価値がありますか？

@enziousは間違いなく可能のようです。 それが価値があるかどうかはあなた次第です:)

@ t-beckmannのソリューションは最も簡単なようです。 それをバックボーン自体に統合する必要がありますか？

私にとっては正しく見えませんが、idAttributeを設定するメソッドがある方が適切ではないでしょうか。

さらに、Promiseのサポートがあれば素晴らしいでしょう。 これは、私が個人的にBackbone内で非推奨になることを望んでいるjqueryDeferredを使用するよりもネイティブなアプローチです。

ここでの話は、最新のツールと言語機能を利用するためにレガシーバックボーンアプリケーションを更新することについてはまだ非常に不明確です。 Symbol.iteratorのようなものが実装されており、製品リリースでは利用できないのを見るのは特に残念です。

この質問に対するより明確な答えをまだ探している人のために、私はTypeScriptをバックボーンアプリに追加しており、このコメントからの解決策が最も役立つことがわかりました。

これまでのところ、十分に機能していますが、より適切な推論を行うのではなく、デコレータを通過したプロパティに明示的に注釈を付ける必要があるという欠点があります。

export function Props<T extends Function>(props: { [x:string]: any }) {
  return function decorator(ctor: T) {
    Object.assign(ctor.prototype, props);
  };
}

@Props({
  routes: {
    home: "home",
    about: "about",
    dashboard: "dashboard",
    blog: "blog",
    products: "products",
    accountSettings: "accountSettings",
    signOut: "signOut",
  },
})
export class Router extends Backbone.Router {
  home() {}
  about() {}
  // ...
}

@Props({
  model: CategoryModel,
  comparator: (item: CategoryModel) => item.display_value,
})
export class CategoryCollection extends Backbone.Collection<CategoryModel> {}

明示的にプロパティアノテーションの例：

@ raffomania 、 @ jridgewell ＆Co。、その価値について、私のチームはクラス外のプロトタイプにidAttributeを追加することでこの問題を回避しました。

クラスExampleはParentExampleを拡張します{
//ここにクラスメソッドなど
}

x.Example =例;

x.Example.prototype.idAttribute = 'customIdAttr';

@kamsciこのブランチでも同じことを行い、BackboneをES6クラスに変換しました

バックボーンは_configuration_を使用して、構成オブジェクトが_declarative_になるようにします。 これは素晴らしいことですが、継承でうまく機能することは決してありません。 （クラスのクローンを作成してから構成します。これは継承ではありません。）

バックボーンを使用して新しいコードを作成する場合は、別の考え方をしてもかまいません。 ES5コードを切り取って貼り付けてから、ES6が機能しないように見せます。 だから何？

configオブジェクトを介してすべてを渡すのにまったく問題はありません。 その構成の内容をどのように公開するか、または読みやすく、操作しやすくするかは、泣くのではなく、解決するための問題です。

コンストラクターを2回実行する必要はありません。 それはばかげています。 しかし、のパターン

Foo = BackboneThing.extend（{LONG DECLARATIVE OBJECT LITERAL}）も母親を愛する醜いです。 あなたは皆、それがどれほど醜いのかわからないほど長い間それをやっています。

参考：私は大規模なMarionetteプロジェクトを持っており、ES6構文を使用したいと考えていました。 Backboneextends宣言をES6クラスに変換するjscodeshiftトランスフォーマーを作成しました。 それは多くの単純化された仮定をしますが、それでも出発点としてだけであるとしても、あなたの何人かにとっては役に立つかもしれません。 これは、デコレータで問題が発生したときに@ t-beckmannによって提案された構文に従います。
https://gist.github.com/maparent/83dfd65a37aaaabc4072b30b67d5a05d

私には、このスレッドに奇妙な誤称があるように思われます。 ES6の「静的プロパティ」は、インスタンス化せずにクラスに存在するコンストラクターのプロパティです（たとえば、Class.extend）。 このスレッドでは、「静的プロパティ」は「静的」値を持つプロトタイプの名前付き属性を参照しているようです（ゲッターや関数ではありません）。 私はそれを正しく理解しましたか？

静的な値を持つプロトタイププロパティの場合、バックボーンの初期化前の値を関数の戻り値として宣言することは非常に簡単な移行であり、_。resultがデフォルト、className、idなどで期待どおりに機能するように機能します。他のインスタンスプロパティはで正常に宣言されているようです。初期化関数の上部は通常どおりです。 この問題は、ES6クラスでは現在静的な値でプロトタイププロパティを定義できず、ゲッター、セッター、および関数のみを定義できるためにのみ発生するようです。

いずれにせよ、コンストラクター/クラスの静的プロパティ（Class.extend）は、ES6の場合のようにバックボーンに継承されません。 バックボーンは、ES6のようにこれらのプロパティを継承するのではなく、extend関数を実行するたびに、クラスの静的プロパティを新しいクラス/コンストラクターにコピーします。 ここでそれを修正するためのPRを作成しましたhttps://github.com/jashkenas/backbone/pull/4235

私はいくつかのコメント/フィードバックをいただければ幸いです、それが何かを壊すかどうかはわかりません、私はそれをかなりテストしました、そしてそれはうまくいくようです。 バックボーンクラスは、新しい各コンストラクターへの参照をコピーするのではなく、後でClass.extendを継承します。