Backbone: Добавить поддержку геттера/сеттера для расширения метода

Созданный на 9 февр. 2015 · 12Комментарии · Источник: jashkenas/backbone

Поскольку геттеры/сеттеры поддерживаются IE9+ и будут гораздо более распространены в ES6, было бы неплохо, если бы метод расширения Backbone поддерживал их.

var Person = Backbone.Model.extend({
  get fullName() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }
});

var elonMusk = new Person({
  firstName: 'Elon', 
  lastName: 'Musk'
});

console.log(person.fullName); // >> Elon Musk

Прямо сейчас это приведет к undefined is not a function , потому что использование _.extend вызывает геттер.

change wontfix

Источник

jamiebuilds

Самый полезный комментарий

Конечно, я сделаю это

jamiebuilds 11 февр. 2015

❤2 🎉1

Все 12 Комментарий

Есть ли какая-то причина, по которой нельзя было бы лучше написать как person.fullName() , чтобы вы знали, что это вызов функции?

Использование геттеров и сеттеров по большей части является плохой идеей в JS, и они идут вразрез с одной из основных идей Backbone Models. Я сомневаюсь, что в ближайшее время вы увидите добавленную поддержку.

akre54 9 февр. 2015

Более того, это будет частично согласовано с синтаксисом нового класса. В синтаксисе класса пока нет инициализаторов свойств или даже какой-либо спецификации для них, поэтому взаимодействие будет проблемой.

они противоречат одной из основных идей магистральных моделей.

Что это за основная идея?

Также геттеры являются частичным решением существующей проблемы в Backbone.Collection с model.idAttribute .

jamiebuilds 9 февр. 2015

Потратил несколько минут, пытаясь сделать jsperf с разными решениями:
http://jsperf.com/backbone-extend-with-define-property

jamiebuilds 9 февр. 2015

Что это за основная идея?

Идея о том, что установка и получение свойства объекта должны быть прозрачными и логичными. Вы всегда должны знать, что obj.prop = val никогда не делает ничего, кроме установки значения этого свойства (то же самое для извлечения), в то время как мы должны использовать функции для обработки таких вещей, как вычисляемые свойства и события изменения. Это основная причина использования методов-оболочек get и set вокруг attributes в первую очередь.

Также геттеры являются частичным решением существующей проблемы в Backbone.Collection с model.idAttribute.

По какой причине текущая оболочка _.result не работает для этого? idAttribute может быть либо примитивом, либо функцией. Это также исправлено с помощью modelId .

akre54 9 февр. 2015

Извините, я должен был сослаться на проблему, о которой говорил: https://github.com/jashkenas/backbone/issues/3408 .

Я упоминаю об этом в основном потому, что синтаксис класса Backbone в значительной степени уже совместим с синтаксисом класса ES, и кажется разумным, что они будут совместимы, учитывая добавленную поддержку coffeescript.

jamiebuilds 10 февр. 2015

CoffeeScript не поддерживает сеттеры и геттеры в основном по тем же причинам (посмотрите на проблемы там для некоторого фона, начиная с https://github.com/jashkenas/coffeescript/pull/2902). Они не должны быть препятствием для поддержки объектов Backbone в качестве классов.

Извините, я должен был сослаться на проблему, о которой говорил: # 3408.

Напомни мне? Я напрягаюсь, чтобы увидеть связь с места в карьер.

Кроме того, любые изменения в extend должны быть сделаны в _.extend , а не здесь. Закрытие как wontfix.

akre54 10 февр. 2015

CoffeeScript не поддерживает сеттеры и геттеры в основном по тем же причинам.

Я не говорил о геттерах/сеттерах, я говорил о том, как Backbone добавил __super__ для взаимодействия с CoffeeScript и что для него имеет смысл только поддерживать классы ES6 таким же образом.

Напомни мне? Я напрягаюсь, чтобы увидеть связь с места в карьер.

Collection.extend({
  model: function() { return Model }
});
//
collection.modelId(model); // 'id' regardless if that's correct or not.

Collection.extend({
  get model() { return Model }
});
//
collection.modelId(model); // correct for *some* of the common cases.

Кроме того, любые изменения для расширения должны быть сделаны в _.extend, а не здесь. Закрытие как wontfix.

Это определенно неподходящее место для этого изменения, во всяком случае, это будет новый метод _.assign . Но гораздо разумнее поддерживать его здесь, ИМО.

Кроме того, прежде чем эта проблема будет закрыта и о ней забудут, я хотел бы объяснить, почему для расширения Backbone нормально иметь проблемы взаимодействия с классами ES, но не с классами CoffeeScript.

jamiebuilds 10 февр. 2015

Что ж, учитывая, что IE Tech Preview — единственный браузер с хоть сколько-нибудь приличной поддержкой class (даже Traceur и 6to5 еще не конвертируют extends ), мы далеки от этого, даже будучи необходимо. Кроме того, Backbone не собирается ломать обратную совместимость только для того, чтобы поддерживать функцию, с которой начинать не стоит.

akre54 10 февр. 2015

даже Traceur и 6to5 еще не конвертируют extends

На самом деле они оба работают, им просто требуется поддержка __proto__ для статических свойств, которая широко поддерживается.

Также нет причин нарушать совместимость с обратными словами, ее можно было бы даже сделать быстрее, если бы она выборочно использовала Object.setPrototypeOf там, где это возможно.

jamiebuilds 10 февр. 2015

@thejameskyle Хотите превратить это в пиар, а не в проблему? Это стоит посмотреть.