Несколько именованных просмотров в UI-маршрутизаторе

Question

Я прошу об этом, чтобы я понял концепцию. В UI Router они рекомендуют использовать как можно больше вложенных состояний. Однако, похоже, когда вы это делаете, у вас может быть только 1 контроллер на состояние/просмотр. Что в большинстве случаев прекрасно. Однако, если вам нужны два или более контроллеров в состоянии/представлении, то кажется, что Multiple Named Views - правильное решение. Потому что кажется, что на самом деле у вас могут быть разные элементы html или div, управляемые разными контроллерами - если необходимо.

Так, например, на странице результатов поиска у вас могут быть разные элементы или divs на странице, управляемые разными контроллерами .... это то, для чего предназначены несколько именованных просмотров в UI Router?

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

Так я правильно понимаю это?

Answer 1

Я думаю, вы смущены фундаментальным определением views и states. При этом ваше понимание (к вашей собственной постановке проблемы) является правильным.

В ui-router основной принцип заключается в том, что приложение превращается в конечный автомат. Основным определением конечной машины является то, что в любой момент времени может оставаться активным только state. Это на самом деле очень полезно и хороший шаблон дизайна - в некотором смысле, вы можете определить, что должен делать ваш компьютер (или приложение) (или как он должен себя вести), когда он находится в ясном определенном состоянии. Хорошо для отладки тоже.

Однако это не означает, что в одном состоянии машина не может выполнять несколько действий. Он может, пока в этом состоянии, должен выполнять несколько действий. Давайте возьмем приложение для бронирования фильмов в качестве примера.

Отказ от ответственности: это не совсем реальная диаграмма состояний, но позволяет просто использовать его для целей обсуждения. Изображение предоставлено Google Search

Теперь все синие округлые прямоугольные прямоугольники являются состояниями. Смысл, когда пользователь использует приложение, в любой момент времени он/она будет находиться в одном из состояний - он должен, или он не использует приложение.

Теперь можно быстро понял, что, если пользователь находится в состоянии SeatsChoosing, он НЕ МОЖЕТ быть в других государствах - не PromotionSelection, не Payment или других государств, одновременно. Он может пойти в другие штаты (так называемый переход государства), скажем PromotionSelection, но только после того, как он сделал выбор. Дело в том, что здесь не более одного государства, а не Параллельных государств. Только по одному.

Хотя это может быть только одно активное состояние одновременно, но это не означает, что машина не может выполнять несколько задач в одном состоянии. В качестве примера возьмем состояние SeatsChoosing. В состоянии SeatsChoosing выполняется несколько задач, включая загрузку фильма, выборку местоположения, отображение расписания и т. Д. Но пользователь будет испытывать все эти вещи, только если он находится в состоянии SeatsChoosing.Дело в том, что вы можете одновременно выполнять несколько задач в одном состоянии, если это позволяет определение состояния.

И это именно то, что достигает ui-router. В любой момент времени в вашем приложении можно активировать только одно состояние. Вложенные состояния по-прежнему представляют собой единое состояние, а на самом деле это узел, пройденный на конечной машине - и когда вы доходите до этого узла, активен только этот узел. Никакие параллельные состояния не допускаются. Точно так же это не означает, что ваше состояние не может одновременно выполнять несколько действий. Вот где named views для. Для состояния вы можете иметь разные представления, которые имеют разные четко определенные контексты (представление), которые все они попадают под один и тот же домен (состояние) в виде большого зонтика.

Теперь вернемся к описанию проблемы с результатами поиска. Как вы определяете свое состояние и как вы определяете свои взгляды? Это полностью зависит от вас, но просто убедитесь, что если вы используете ui-router, вы придерживаетесь правил конечного автомата, а не параллельных состояний, но допускаете параллельные задачи. Поэтому, если вы определяете состояние, это страница, которая выполняет несколько действий - аутентификацию, автозаполнение и т. Д., То да несколько именованных представлений - это правильный путь, а не вложенные состояния. Но если вы отделяете search и search results как два разных домена, то, возможно, вложенные состояния будут лучше.

Для этого нет правильного и неправильного ответа, просто вопрос конструктивного решения.

Надеюсь, что это поможет.