Как рендерить во view, дожидаясь загрузки данных по ajax в model?

Question

[Павел]

app.init = function() {
     this.model.load('tabs');
     this.view.render('tabs');
}
app.model = {
    load : function(entity) {
        $.getJSON( entity+'.json', json => this[entity] = json);
    }
}

app.view = {
    render: function(entity) {
         jsonToHmtl(app.model[entity]);
    }
}

function jsonToHtml(json) {
    // рендер lodash
}

Как сказать рендеру, что можно рендерить полученный json, учитывая mvc-паттерн? Или я чего-то не понимаю в этой жизни о_о

Answer 1

[bromzh]

Да, ты не понимаешь асинхронность в JS и MVC.
Нужно рендерить после получения данных. Например, можно вызывать функцию render в колбеке getJSON. Ещё лучше вернуть промис и вызывать рендрер в колбеке then.
Но это всё равно ни разу не MVC.

А не могли бы вы помочь, как это делать в парадигме MVC?

Ну тут всё не так просто. Если ты хочешь использовать MVC-фреймворки, то смотри, как там всё организовано у них. Примеры реализации простого MVC приложения см. тут.

Если же забыть про тонны готовых MVC, то можно сделать всё самому. Тут важно понимать, что:
1) Модель - это вся бизнес-логика. И она не знает ни про View, ни про Controller. В классическом MVC модель оповещает всех подписчиков об изменении своих данных.
2) Вид (view) должен знать про модель, но не про контроллер. В классическом MVC вид подписывается на события модели и при возникновении события он перерисовывается.
3) Контроллер знает про вид и про модель. В классическом MVC он связывается с каким-то видом и при определённом действии пользователя что-то делает. Например, он может вызывать какие-то методы у модели. А может и изменять состояния вида (хотя так лучше не делать в идеале, так как повысится связность системы, что плохо).

Итак, вот тебе пример. Немного корявый, но суть должна быть ясна.

Сперва посмотри в script.js.

Там есть класс-модель. Чтобы связать Model и View обычно применяют паттерн проектирования observer. У модели есть список слушателей. Каждый слушатель - просто функция-коллбек, которая принимает 1 аргумент - данные этой модели. При этом, сама модель не знает вообще ни про какой View. Слушатели в модели - это просто массив функций, которые будут вызваны.
В модели есть метод для добавления слушателя и для оповещения всех слушателей о получении новых данных. Метод getData эмулирует асинхронный запрос данных. В этом методе создаётся промис. Если данные найдены, то вызывается метод оповещения всех слушателей и промис резолвится. Если данные не найдены, то промис реджектится.

Далее, небольшая иерархия view-классов.
Класс BaseView. Там есть конструктор, который связывает экземпляр класса с DOM-элементом; метод subscribe, который добавляет к модели простого слушателя. Слушатель вызывает метод render с данными, которые нужно отрендерить и записывает полученный из метода render HTML в элемент. В самом классе BaseView метод render выплюнет ошибку, так что нужно написать несколько классов-наследников.
Класс ListView наследуется от BaseView и просто добавляет вспомогательный метод, который просто обрамляет каждый объект из массива с данными в элемент .
Ну и наконец, есть 2 класса, которые непосредственно реализуют метод render.
В итоге, класс UlView генерирует из массива данных ненумерованный список, а класс OlView - нумерованный.

Теперь в самом index.html можно увидеть всё в деле. Создаём модель и 2 view. Каждый view инициализируем соответствующим div-элементом. Далее,
При нажатии на кнопку вызывается коллбек, который вызывает метод модели. Если модель смогла получить данные, то подписанные на эту модель вьюхи рендерят эти данные, причём каждый view делает это по-разному. Как тут можно заметить, модель вообще никак не зависит от view. Можно связывать сколько угодно вьюх без какого-либо изменения самой модели.

В общем, как-то так. Это конечно очень простой и довольно корявый пример (например, тут нет возможности связать контроллер и сам view, это уж сам изучи), так что не следует этот код использовать где-то в своих проектах.
Ну и почитай ещё про MVC, посмотри реализацию TodoMVC на разных фреймворках.

Comments

[Павел]

А не могли бы вы помочь, как это делать в парадигме MVC?

[Павел]

Спасибо! Довольно доходчиво.
Как я понял из примера вашего, он совершенно не юзабелен в продакшене по причине использования классов через class, а его поддержка еще долгое время не будет широкой поддержки (умеет babel, конечно, но ни nodejs, ни подавляющее число браузеров нет).
Я сейчас столкнулся с проблемой, что постиг множество инструментов (и постигаю еще), и не очень понимаю, когда нужно использовать тот или иной. Понятное дело, что есть просто различные практики, и в одной из них принято писать так, а в других - сяк. Но все же, порой, хотелось бы увидеть в серьезной книжке что-то вроде, "get/set надо применять в таких ситуациях (a,b,c), а вот в (d,e,f) их не нужно применять".
При этом книжки, написанные для новичков, читать противно. Очень много лишней информации, а вся новая преподносится на бэйсик-уровне.
Можете чего посоветовать? Из личного, так сказать, опыта.

[bromzh]

Павел: см. тут https://kangax.github.io/compat-table/es6/
А вообще так: почти все синтаксические штуки использовать можно. Главное, обработать всё предварительно babel'ом. А новая нода умеет многие штуки из es6 нативно. Для сборки всего я рекомендую webpack. Он ещё и круто работает с импортами (в том числе, в стиле es6), так что никаких доп. загрузчиков (типа Systemjs) не понадобится.

Другие же нововведения стоит использовать с осторожностью. Если неизвестно, какой будет браузер у пользователя, то лучше использовать полифиллы.

Чтобы ещё точнее узнать, заработает ли твоё приложение, достаточно написать e2e- и unit-тесты и запускать их (например через karma) на разных браузерах и разных версиях этих браузеров.

[Павел]

bromzh: спасибо, добрый человек