Запрещение breeze.js создавать наблюдаемые свойства для объектов массива

Я должен упустить что-то простое, но не могу понять. Я получаю кучу таблиц поиска за 1 вызов веб-API.

return EntityQuery.from('Lookups')
       .noTracking(true)
       .using(manager).execute()
       .then(processLookups);

В processLookups я вызываю getLocal для каждого возвращенного массива. Пример: таблица состояний

 datacontext.lookups = {
     state: getLocal('States', orderBy.state, true),
     ....
 }

function getLocal(resource, ordering, includeNullos) {

    var query = EntityQuery.from(resource)
        .orderBy(ordering)
        .noTracking(true);

    if (!includeNullos) {
        query = query.where('id', '!=', 0);
    }
    return manager.executeQueryLocally(query);
}

Массивы не наблюдаемы, но каждое свойство в объектах массива является наблюдаемой функцией. Это просто накладные расходы, которые мне не нужны, поскольку они не будут меняться.

Как я могу предотвратить наблюдаемые свойства объекта?

Спасибо


observable properties breeze
person mwill    schedule 18.02.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Необработанные поиски доступны вам прямо в обратном вызове успеха из запроса. Нет причин смотреть на кеш ... даже если они были там (чего нет, как ясно дает понять Джей).

Но что бы вы ДЕЛАЛИ с этими поисками? Предположительно, вы хотите, чтобы они были связаны (путями навигации Breeze) с реальными объектами. Например, вы хотите, чтобы session.room возвращал связанный объект комнаты. Но если комната является одним из ваших поисковых запросов и НЕ является сущностью, то свойство навигации session.room не вернет ее; свойства nav всегда возвращают объекты.

Я могу придумать способы обойти это. Но это просто больше работы и больше хитрости.

Давайте остановимся на мгновение и зададим самый важный вопрос: Почему?

Почему вас волнует, являются ли поисковые запросы объектами с наблюдаемыми свойствами? Это может быть "накладные расходы, которые вам не нужны". Но вредят ли вам накладные расходы? Тебе больно как? Вы измерили это?

Простите, но я чувствую преждевременные оптимизации, которые могут отвлечь вас от более достойных занятий. Рад оказаться неправым.

person Ward    schedule 19.02.2015
comment
Я понимаю, что вы имеете в виду под отсутствием отслеживания. Я просто пытался взять приложение CodeCamper Jump Start Джона Папы и настроить его, думая, что noTracking — это то, что мне нужно. (За исключением noTracking, приведенный выше код взят прямо из его примера). Вы правы, необработанный JSON доступен в обратном вызове, я могу просто использовать эти массивы. Свойства как функции совсем не помешают, но в этом сценарии они не добавляют никаких преимуществ (например, свойство nav). Спасибо, парни. - person mwill; 19.02.2015

arrow_upward
1
arrow_downward

Я не уверен, что полностью понимаю ситуацию, но опция «noTracking» действительно актуальна только для «удаленных» запросов. то есть не местные. По сути, «noTracking» говорит бризу не обрабатывать результаты запроса в объекты бриза, А ТАКЖЕ не кэшировать эти результаты.

Когда вы запрашиваете кеш, что и делает «executeQueryLocally», оба эти шага уже выполнены, поэтому «noTracking» игнорируется.

person Jay Traband    schedule 19.02.2015