Ember Routes vs Controllers vs Views

Я прочитал большинство руководств для новичков на сайте Ember.js, но я до сих пор смущен правильным местом для размещения вещей.

  • Маршрут - из онлайн-исследований люди предложили включить маршрутизацию в логику маршрута. Это все хорошо, но единственное, о чем я могу думать, - это this.transisionTo(). Я читал где-то еще, что все связанные с моделью операции должны быть на маршруте, потому что здесь определено поле model. Это верно? Каковы некоторые хорошие варианты использования actions в маршруте через контроллер?

  • Просмотр. В настоящее время я не вижу точку зрения. Документы говорят, что он обрабатывает собственные DOM-события, но я, вероятно, всегда буду использовать помощник {{action}}, который будет обрабатываться контроллером. Итак, каковы некоторые хорошие примеры использования представления над контроллером в отношении действий? Каковы некоторые хорошие варианты использования представления, в общем, учитывая, что я буду использовать компоненты над представлениями для многоразового кода.

  • Контроллер. Мне кажется, что контроллер может делать все, что может сделать View или Route. Он может перейти с помощью this.transitionToRoute(), он может сохранять модели с помощью this.get('model').save() и может обрабатывать действия с помощью помощника {{action}}. Все начинающие учебники, похоже, вообще игнорируют представление и вместо этого используют контроллер. Каковы некоторые примеры использования контроллера при просмотре или маршруте?

Я думаю, все это сводится к плохому пониманию того, как все висит вместе. Я не могу найти что-либо в Интернете или в документах, в которых явно указаны серые области, например, где использовать помощник {{action}} для разных сценариев. Ссылки на некоторые хорошие материалы также будут полезны.

Ответы

Ответ 1

Обновление: Не вся эта информация будет корректной для Ember 2. Насколько я знаю, Ember 2.0 будет использовать только компоненты.

Как различные компоненты Ember.js Fit Together

Model

Модель заботится о взаимодействии с хранилищем данных. Примером хранилища данных может быть сервер RESTful или Localstorage.

Шаблон

Шаблон заботится о создании HTML из данных, доступных его контроллеру и представлению. Контроллер, в свою очередь, имеет доступ к модели.

Контроллер и просмотр

Контроллеры и представления очень похожи и действуют на пользовательские события. Предполагается, что контроллер должен принять меры в отношении семантических событий, таких как submit, и предполагается, что представление должно принять меры для таких событий взаимодействия, как focus или click.

Router

У Ember есть один Router. Маршрутизатор связывает URL-адреса с маршрутами. Например users/:user_id to users.show route или UsersShowRoute.

Маршрут

Каждый Маршрут, когда активирован, заботится о распаковке URL-адреса в состояние. Например, users/:user_id требует, чтобы пользователь вошел в систему, чтобы увидеть профиль друзей. Маршрут гарантирует, что пользователь выполнит вход в систему и позаботится о состоянии входа в систему.

Маршрут получает информацию из хранилища данных. Например, users/pekhee будет извлекать пользователя pekhee из хранилища данных и передавать его контроллеру и представлению.

Маршрут динамически выбирает, какой контроллер и просмотр ему нужно или сколько из них ему нужно.

Маршрут управляет состоянием приложения и как его должно представлять. Однако модели заботятся об управлении состоянием приложения для Route и Controllers/Views, заботясь об управлении подробными подробностями своего представления.

Сохранять логику как актуальную, так и локальную: Некоторые заметки

  • Если ваша логика не заботится о каком-либо контексте или модели, поместите ее в activate обратный вызов маршрута.
  • Если кусочек логики должен знать только модель, поместите ее в afterModel обратный вызов маршрута.
  • Если ему нужно знать контекст контроллера или взаимодействовать с семантическим значением ресурса, поставьте его в контроллер.
  • Если ему нужно знать контекст View или взаимодействовать с представлением ресурса, поместите его в представление.
  • Если он должен знать оба контекста или взаимодействовать как с семантикой, так и с представлением ресурса, сначала дать событию представление, а затем перевести его в контроллер.

Примеры

Когда несколько контроллеров работают с одной моделью, сохраняйте семантические действия на максимально возможном маршруте в цепочке, иначе сохраняйте логику в большинстве локальных контроллеров.

Сохраняйте код, связанный с анимацией, в представлении и используйте Liquid Fire.

Иногда у каждого пользователя много сообщений, и у каждого сообщения есть много комментариев. Попытайтесь, чтобы маршрут возвращался к соответствующему пользователю. Затем спросите соответствующего пользователя для сообщений в PostsRoute и после этого попробуйте запросить соответствующие комментарии в CommentsRoute. Это позволяет логике как можно более локально. Маршрут комментариев не должен знать, как вы извлекаете пользователя.

Ответ 2

Я думаю, что ember2.0 должен отказаться от просмотра и контроллеров, он хочет сделать ваши коды более многоразовыми, и почему компоненты более приветствуются. В интересах размещения действий на маршруте вместо контроллеров я могу только видеть, что он облегчает понимание ember для новых пользователей. Вам не нужно тратить много времени на попытку понять взаимосвязь между контроллером, маршрутом, маршрутизатором, представлением и шаблоном. Это мое предположение, хотя.