Создание слабосвязанного и многостраничного приложения JS с использованием шаблона Core (Mediator)/Sandbox (Facade)/Module - рекомендации?

Ответ 1

Одна вещь, которую мы сделали, чтобы история работала гладко, заключалась в том, чтобы сначала изменить URL. При изменении URL-адреса событие будет запущено, маршрутизатор проанализирует URL-адрес, затем выяснит, что делать. Это событие автоматически активируется при загрузке страницы. Если вы щелкнете ссылку, она просто изменит URL-адрес, который довольно прост и полностью отделяет ссылки/кнопки от логики приложения. Казалось, это хорошо работает для нашего приложения. Мы использовали JQM, но мы потеряли большую часть своего маршрутизатора, так как мы прочитали большинство наших инструкций из некоторого файла XML и не имели кучу HTML-страниц для загрузки в основную область области просмотра.

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

То, что я не обязательно соглашался с Backbone on, было его определением "взглядов". Вид вроде похоже на действие в контроллере (ну с некоторых точек зрения). В этот момент мы добавили еще один уровень разделения. Наши представления сделали запросы ajax к файлам шаблонов, которые были заполнены некоторыми JSON и handlebars.js. Я бы сказал, что ваш заголовок/боковая панель должны быть просто шаблонами. Если вам нужно обновить их, посмотрите, как вы могли бы сделать это очень просто, иначе вы смотрите на создание 4 новых модулей: сборка для списка, модели для каждого элемента, вида коллекции и представления модели. Я собирал несколько шаблонов с более высоким уровнем, пока они не будут разбиты дальше (например, некоторые "Приложение/Основной вид" ).

Наличие этого слоя шаблона позволяет сделать поверхностные изменения без перекомпиляции, что тоже приятно. Каждый раз, когда вы можете помещать вещи в "мета", это выигрыш (ну, если он не требует, чтобы вы читали XML (ha)). В качестве бонуса вы также можете кэшировать этот шаблон отдельно (или, к сожалению, его портить отдельно).

Ваша архитектура действительно кажется прекрасной, и это действительный подход к вашей проблеме. Один совет, который я бы дал, - это не дизайн. Итерация лучше. Вам понадобится рефакторинг. Невозможно предвидеть, что сделало бы ваше приложение более плавным за 3-6 месяцев вперед.

Обновление от 18 декабря 2013 г.

Теперь мы используем марионетку и более трюки addy osmani. В дополнение к перечисленным выше элементам мы используем альтернативный формат AMD:

define(function(require) {
    var myTemplate = require('hb!mytemplate.handlebars'),
        view = require('myview');
    ...
});

Мы также используем класс приложений marionette в сочетании с wreqr, который обеспечивает уровень запроса/ответа. Это позволяет нам легко устанавливать объекты широкого применения. Это также позволяет нам определять классы без явного указания имени класса. Это довольно хороший способ для песочницы. EG:

this.app.setHandler('CanvasClass', function() {
    return RaphaelCanvasView;
});

// elsewhere

this.app.request('CanvasClass').text('123', {x:1, y:2});

Все это, похоже, очень хорошо работает.

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

Ответ 2

Я думаю, что это хороший подход. Я развиваю что-то подобное в двух огромных коммерческих веб-приложениях (минус позвоночник и с помощью менеджера по истории), и он отлично работает. Я также не использую AMD, и все взаимодействия обрабатываются pub/sub. Одно из моих лучших впечатлений (которое, я уверен, вы уже знаете): https://github.com/aurajs/aura