0

У меня есть базовая коллекция, в которой пользователи выполняют действия типа CRUD. Я хочу отложить любые изменения от распространения на сервер - Collection.sync() не должен происходить, пока пользователь не инициирует его (например, POSTING).Отложить синхронизацию коллекции Backbone.js с сервером

Как бы то ни было, я смог внедрить «на лету» обновления без проблем (путем вызова таких вещей, как Model.destroy() на моделях при удалении, или Collection.add(), чтобы добавить новые модели в коллекцию. Насколько я понимаю, я может передать опцию {silent:true} в моей модели, предотвращая .sync() от вызова во время .add()/.destroy(), но от того, что я могу сказать, что может привести к некоторому headaches later.

Я рассмотрел перекрывая Backbone.sync, но я не уверен, если это лучший способ - я чувствую, что есть какой-то способ подключиться к некоторым событиям, но я не уверен. Конечно, я прочитал документы Backbone, аннотированный sou rce и соответствующие вопросы SO перед публикацией этого, но я ударил стену, пытаясь экстраполировать эту ситуацию.

В конце концов, мне нужно будет реализовать это во многих местах моего приложения, поэтому я обеспокоен лучшими практиками на этом этапе. Я ищу несколько советов/предложений/соображений о том, как продолжать предотвращать поведение по умолчанию, которое немедленно синхронизирует изменения с удаленным сервером. Любая помощь приветствуется - спасибо за ваше время!

EDIT:

Я пошел с предложением Alex P о рефакторинге: в моей коллекции я создал некоторые атрибуты для отслеживания моделей, которые были отредактированы, добавлен или удален. Затем, когда пользователь запускает действие сохранения, я повторяю списки и выполняю соответствующие действия.

+2

Нет ничего плохого в '{silent: true}', он существует из-за этих ситуаций _rare_. –

+0

@akoskm: Спасибо! Похоже, вы подразумеваете, что это необычный случай использования - вы думаете, что я рассматриваю эту функцию с плохой точки зрения? Я чувствую, что то, что я здесь, не слишком сумасшедший, но, основываясь на своем исследовании, я все время чувствую, что я пытаюсь сделать то, что не рекомендуется или не предлагается. –

+0

Если это заставляет вас чувствовать себя лучше, я тоже использую его. :) И я делаю это в производстве, а не в приложении Todo. '{silent: true}' решил ту же проблему для меня. Если вы ищете решение, которое работает, то идите с этим. –

ответ

1

Первый шаг - обеспечить синхронизацию вашей коллекции, если вы ее подозреваете. Collection.add() не должен запускать Collection.sync() по умолчанию (он не указан в the method documentation или list of events, и я не видел триггера в the annotated source).

Model.destroy()does trigger a sync(), но это не должно быть сюрпризом, - это явно определяется как «уничтожение модели на сервере», и что sync() выполняется на модели, а не сбор. Ваши разрушенные модели будут удалены из любых коллекций, содержащих их, но я бы не ожидал, что эти коллекции будут sync(), если они явно не заданы.

Если ваши коллекции действительно являются sync() ing, когда вы их не ожидаете, то наиболее вероятным виновником является прослушиватель событий где-то. Добавили ли вы прослушивателей событий, которые звонили sync() для вас, когда они видят add или remove событий? Если ваша коллекция должна быть sync() только при взаимодействии с пользователем, можете ли вы удалить эти прослушиватели событий?

Если нет, то передача {silent: true} в ваши методы может быть жизнеспособным подходом. Но помните, что это просто останавливает события от испускания - это не останавливает выполнение этого кода. Если что-то, кроме прослушивателя событий, вызывает ваш sync() с, то предотвращение этих событий не будет их останавливать.

Было бы также полезно рассмотреть более широкий рефактор вашего приложения. Сейчас вы сразу изменяете коллекцию и модели и пытаетесь отложить все sync() s до тех пор, пока пользователь не нажмет кнопку.Что делать, если вы кэшировали список всех моделей для уничтожения & элементов для добавления и выполняли только действия при нажатии кнопки? Хранение идентификаторов модели было бы достаточно для их уничтожения, и сохранение идентификатора коллекции и идентификатора модели позволит вам добавлять элементы. Это также означает, что вам не нужно снова fetch(), если пользователь решит не сохранять свои изменения в конце концов.

+0

«Что делать, если вы кэшировали список»: в какой-то момент я очень серьезно относился к этому вопросу, но казалось, что может быть более эффективный способ использования Backbone. Однако, видя ваше предложение, я думаю, что стоит пересмотреть --- спасибо! –