Marionette.js, как правильно хранить коллекцию, которая используется несколькими модулями?
Направьте на путь истинный!
Может я чего то не понимаю, но если более предметно говорить то у нас есть, к примеру, коллекция пользователей (она должна всегда быть в актуальном состоянии, то есть регулярно синхронизируется с сервером), в модуле управления пользователями мы создаем\редактируем etc... , соответственно есть другой модуль в котором нам надо знать все о всех пользователях. Собственно как такое правильно делать?
Единственный вариант который я вижу, так это хранить в одном модуле, а другой модуль будет получать через request/response. Но в этом случае встает вопрос что делать если модуль в котором хранится коллекция был остановлен...
PS: Если вопрос немного сумбурный, уточняйте детали :) я еще только в процессе изучения марионетки
Если я правильно понимаю, для того что бы перестать слушать события и грохнуть вьюшку, надо остановить модуль. Может быть я не с той стороны подхожу к вопросу, мне видится такая реализация: в меню тыкнули в раздел "пользователи", запустился модуль пользователей, со своими суб. модулями etc, когда тыкаем в другой пункт меню (например в dashboard), модуль пользователей стопается и запускается другой. Такой подход не best?
aen: прошу прощения, а можно поподробнее, где почитать, что от модулей марионетки будут отказываться и что предложат в замен? ибо они же сейчас часть app и вроде как много с ними фишек, да и различные пособия, книги и скринкасты советуют на них строить архитектуру приложения (пусть они (справочный материал) и не самые актуальные)...
aen: ну я собственно тоже о Marionette.Module писал
во многих учебных материалах эти модули юзаются как базовые кирпичики аппликейшена на марионетке, я хз, как оно в боевых условиях, ибо начал только-только юзать марионетку в работе, по мне так такой класс норм вписывается в модульную архитектуру, только немного нелепо выглядит конструкция создания модуля, когда юзаешь еще поверх обертку модуля от require.js, к примеру
Мне вообще кажется бессмысленным в рамках какого-то фреймворка решать вопросы с модульностью. Это удел amd/commonjs/es6. Свои костыли ни к чему хорошему не приведут.
Насколько я знаю, модули в марионетке были чуть ли не с самого начала. Видимо, Дерик Бейли их придумал еще до того как познакомился с require.js, а затем перешел на commonjs + browserify.
MitoZ: Я так и думал. У David Sulc только последняя книга более менее актуальная, остальное уже слегка устарело. Скринкасты меня вообще печалят. Сколько я их не смотрел - нет ничего путного. Хоть самому садись и записывай.
aen посоветуйте, как быть в случае если я хочу все приложение собрать одним файлом (с помощью чего либо, Grunt там или Gulp), но при этом не хочу использовать модули Marionette? Как организовать все это дело? Делать примерно как в Backbone, создать один глобальный объект, и аттачить все в него? Или есть подходы лучше? Дмитрий Борковский <"...нелепо выглядит конструкция создания модуля, когда юзаешь еще поверх обертку модуля от require.js, к примеру"> так делать не стоит) оно естественно нелепо получится) достаточно модулей от require.js, с ним кстати все достаточно красиво и логично получается, я использовал Yeoman генератор https://github.com/opus-online/generator-marionett... только там версии старые, надо обновить и чуть подправить, а так структура и организация мне понравились
Если вам нужно, чтобы ваша коллекция работала и была доступна всегда, то нет никакого смысла хранить ее в модуле, в котором есть что-то еще. Она отдельная сущность, доступ к которой вам нужно организовать через шину событий, которую вам даст Backbone.Wreqr.
В вашем описании "модуль пользователей" не тождественнен коллекции. Насколько я понимаю, у вас есть некий кусок логики, который отвечает за пользователей и который работает с коллекцией. Тогда в вашем случае вам надо выключать только этот кусок логики, а коллекцию оставить в покое. Тогда доступ к ней будет всегда.
Не пользовался Marionette.js, но в ember.js сделано так - существует хранилище (store) которое хранит в себе модели, догружает недостающие и отдает их по запросу. Само хранилище через dependency injection доступно во всех местах где это надо (в роуте, в контроллере и тд.) Хранилище инициализируется во время старта приложения и никак не выключается, это независимый объект. Вполне зачетное решение.
