Как избежать пустой записи, когда запрошенный идентификатор не существует? (Эмбер)

У меня есть следующая модель (упрощенная для этого вопроса):

App.Manager = DS.Model.extend({
  name: DS.attr('string'),

  teamMembers: DS.hasMany('App.Employee')
});

Когда эта модель загружается (скажем, с App.Manager.find(1)), она возвращается с моего сервера с массивом teamMembers:

[10, 11, 12]

Моему представлению нужны данные от этих членов команды, поэтому Ember автоматически загружает их с запросом findMany(), как и ожидалось. Проблема, с которой я сталкиваюсь, заключается в том, что сотрудника № 11 не существует. Сервер отвечает на запрос findMany() только сотрудниками 10 и 12:

{
  "employees": [
    {
      "id":   10,
      "name": "John Doe"
    },

    {
      "id":   12,
      "name": "Jane Doe"
    }
}

Но Ember-Data, кажется, по-прежнему держит пустое (и выполненное) обещание для Сотрудника 11, даже несмотря на то, что данные для этого сотрудника так и не были возвращены. Итак, теперь, когда мое представление отображается, я получаю таблицу с 3 строками (по одной для каждого сотрудника), и одна из этих строк полностью пуста (поскольку запись пуста).

Проверяем состояние записи:

{
    isLoaded:  true,
    isDirty:   false,
    isSaving:  false,
    isDeleted: false,
    isError:   false,
    isNew:     false,
    isValid:   true
}

Итак, я не уверен, как сохранить эту пустую запись вне поля зрения, не проверяя, является ли каждое свойство, которое мне нужно, пустым. Есть ли способ ответить серверу, который скажет Ember не выполнять это обещание? Есть ли способ настроить ember для распознавания, когда данные не возвращаются?

Изменить: я понимаю, что в идеале сервер не должен возвращать идентификатор несуществующего сотрудника. Но реальность такова, что иногда данные ненадежны или плохо поддерживаются. Если бы сотрудник 11 возвращался с неточными данными, я бы согласился, что проблема в данных и/или сервисе, а не в Ember. Однако в данном случае сотрудник 11 не возвращает неверные данные, а возвращает НЕТ данных вообще. В этом случае мне кажется, что ember должен, как минимум, установить флаг (т.е. isValid: false), указывающий, что запись пуста/недействительна/не найдена, а то и вовсе уничтожить ссылку на пустую запись.

Изменить 2: вот проблема на Github


javascript model-view-controller ember.js ember-data
person KOGI    schedule 20.02.2013    source источник
comment
Разве это не проблема вашего бэкенда, а не самого Ember? Конечно, в идеальном мире Эмбер исключил бы невозвращенную сущность. Почему ваш бэкенд возвращает [10, 11, 12], когда 11 не существует? Конечно, ваш бэкэнд не должен включать 11, если на бэкэнде не происходит какое-то кэширование.   -  person Wildhoney    schedule 21.02.2013
comment
@Wildhoney ты прав. В конечном счете, сервер вообще не должен отправлять 11 обратно. Я еще не понял, почему он отправляет обратно несуществующий идентификатор, но мне кажется, что ember должен быть достаточно умен, чтобы изящно справиться с этим.   -  person KOGI    schedule 21.02.2013

Ответы (1)


arrow_upward
1
arrow_downward

Трудно сказать, должны ли Ember-данные попытаться обеспечить какое-то волшебство для этого сценария. Включив идентификатор в отношения, вы фактически сообщили ember-data, что они существуют.

Адаптер REST (который запрашивает данные с сервера) отделен от сериализатора (который преобразует данные ответа в ваши модели), поэтому было бы трудно узнать, действительно ли были возвращены все запрошенные данные. Если вы не возражаете против тесной связи вашего адаптера с вашим сериализатором, вы можете убедиться, что сервер дал вам все, что вы ожидали.

Временное решение:

Добавьте свойство проверки в модель сотрудника, чтобы использовать ее в качестве своего рода псевдосостояния. По умолчанию это должно быть false или null, и каждая запись, которую возвращает ваш API, должна перезаписывать ее. Довольно хакерский. К счастью, та же самая концепция может быть реализована с использованием существующего свойства, такого как имя сотрудника.

if (App.Employee.find(11).get('name') != null) { dance('thriller'); }

Если вы рассматриваете описанную выше концепцию как стандартное требование проверки, вы можете реализовать ее как таковую либо в модели, либо в сериализаторе.

person Jon Kirkman    schedule 22.02.2013
comment
Похоже, что оставшийся адаптер должен быть в состоянии сказать, поскольку он знает, какие записи он запросил, и после того, как сериализатор выполнен, адаптер знает, какие записи у нас теперь есть. Мне придется провести некоторые эксперименты после того, как я уберу еще несколько вещей с моей тарелки. - person KOGI; 22.02.2013
comment
Кроме того, когда Ember-data разрешает отношения, все, что он на самом деле делает, — это автоматический findMany([id,id,id]). Если бы вы вручную выполнили тот же вызов findMany() с недопустимыми идентификаторами, у вас возникла бы та же проблема. Может быть, у сервера должен быть способ указать на проблему, возвращая при этом действительные результаты? {"employees": [ { "id": 10, "name": "Jon Doe" }, { "id": 11, "isError": true }, { "id": 12, "name": "Jane Doe" } ] }. Просто из-под манжеты, я не знаю... - person KOGI; 22.02.2013