Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Не нужно, всё-таки, переводить дословно singleton и helper. Эти термины давно и успешно транслитерировались.
стоит использовать Ember, который сразу предлагает производительность и низкий порог вхождения для разработчика
Чего-чего? Я недавно начал изучать Ember (сам пишу на рельсах) и это просто ад для новичка. С каких пор роуты рендерят темлейты и возвращают модели? Нафига вьюхи и где разница между ними, компонентами и темплейтами? А теперь еще контроллеры захотели убрать. Что за каша, зачем так усложнять? Я и так долго думаю в какие части этого эмбера засунуть нужный кусок кода и откуда что доступно. Простые вещи превращаются в часы планирования. Может быть со временем привыкнешь (как и ко всему) и не будешь думать куда что написать, но говорить что эмбер имеет легкий порок вхождения — это эребор.
> С каких пор роуты рендерят темлейты
Не могли бы вы подробнее остановиться на этом моменте? Это ведь довольно распространенная практика что за путём регистрируется лишь шаблон.
Не могли бы вы подробнее остановиться на этом моменте? Это ведь довольно распространенная практика что за путём регистрируется лишь шаблон.
Спасибо за ссылки, но что плохого в том что «роуты рендерят темлейты»?
Это отличается от MVC, где за это отвечают контроллеры. Многим это не нравится, так как предлагается другой подход, причем контроллеры вообще хотят убрать из Ember заменив на компоненты.
Подробнее тут — Контроллеры
Подробнее тут — Контроллеры
Ничего подобного, отличие лишь в том что входной точкой является шаблон. А шаблон может состоять лишь с одного компонента, например
<Users/>так как шаблон разрешает создавать композицию из контроллеров
Это вы говорите о компонентах, для маршрута может быть только один соответствующий контроллер.
Компоненты можно тоже по принципу MVC строить, или одному из его вариаций.
> для маршрута может быть только один соответствующий контроллер
Это если только жестко привязываться к «Роут-Контроллер» архитектуре, но достаточно ввести между ними шаблон и уже можно комбинировать. И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.
> для маршрута может быть только один соответствующий контроллер
Это если только жестко привязываться к «Роут-Контроллер» архитектуре, но достаточно ввести между ними шаблон и уже можно комбинировать. И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.
И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.
Потом уходит само (ненужное здесь, по большому счету) понятие «контроллера» и это просто называется компонентом :)
Ну как же, контроллер и компонент это разные вещи. Компонентом называют законченную единицу интерфейса/приложения — и он как раз состоит из контроллера, или шаблона, или только модели, также может другие ресурсы и компоненты включать в себя. Вообщем компоновать все это вещи можно как угодно. Здесь «компонент» был назван в контексте HMVC.
Дурная практика, на самом деле. Состояние в урле — это такое же состояние, как и состояние в локальном хранилище и состояние на сервере. В идеале работа со всеми этими состояниями должна быть единообразной. Более того, зачастую то какую страничку показать зависит сразу от нескольких типов состояний (конфиг пользователя с сервера, урл с переопределениями, локальное хранилище с теми данными, что не хотелось бы держать в урле).
Вовсе нет. Шаблон в данном случае как middleware между роутом и контроллером, смотрите пример выше про Users. А всё вами описанное можно реализовать или «по-старинке» или же через композицию. Последнее намного удобнее.
Я не про шаблоны в данном случае, а про роуты. Состояние UI зависит не только и не столько от URL. Яркий пример — позиция проигрывания видео на вытрубе. Сохраняется в локальное хранилище, но может быть перегружена через URL.
В сочетании с паттерном DDAU и механизмом визуализации Glimmer разработчики Ember изначально имеют в своем распоряжении и производительность и эффективность.Надеюсь они сотворили там чудо, ибо первая версия в два раза медленнее даже ангуляра: nin-jin.github.io/todomvc/benchmark
Кто бы написал ToDoMVC на Ember2?
В Ember 2 производительность хорошо подтянули.
Свежее сравнение Ember 1, Ember 2, React и IDOM можно посмотреть в этом обзоре (En).
Свежее сравнение Ember 1, Ember 2, React и IDOM можно посмотреть в этом обзоре (En).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ember.js — прощай MVC (часть 1)