Сайт AngularJS - полный или частичный

Question

Сайт AngularJS - полный или частичный

0

Я хотел бы создать новый веб-сайт с помощью AngularJS. Идея состоит в том, чтобы создать API-интерфейс на стороне сервера с Ruby on Rails, которые обслуживают Json для front-end AngularJS.

Мой вопрос: лучше ли создавать полный интерфейс AngluarJS или стандартный рубин на интерфейсе рельсов с некоторым угловым?

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

Например, я задаюсь вопросом, не помешает ли какое-то изменение в угловой странице 1, которая должна изменить страницу 2. Эта страница 2 не будет обновляться до тех пор, пока на странице не будет предпринято действие или пользователь не перезагрузит страницу.

Что-то не так в моем подходе? Что вы посоветуете?

Спасибо за прочтение.

Yohan Béjannin 03 июль 2015, в 15:34

Теги:

2 ответа

0

Механизм маршрутизации в угловом режиме находится только в одном объекте окна.

Если у вас есть два окна, у вас будет два угловых приложения. Если вы хотите установить связь между угловым объектом окна, не предусмотрен какой-либо специальный механизм, кроме стандартных HTML и javascript.

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

borja gómez 03 июль 2015, в 11:45

0

Спасибо за Ваш ответ. Что вы подразумеваете под одним объектом окна? У меня может быть меню с несколькими различными страницами (список A, список B, например), все в одном приложении Angular. Вероятно, у меня будет один контроллер на странице, но только одно приложение Angular. Не так ли?
Yohan Béjannin 03 июль 2015, в 13:36
0

Да, у вас есть столько контроллеров, сколько вы хотите, и вы можете перемещаться между ними, но вся навигация происходит внутри одного и того же оконного объекта, поэтому он называется одностраничным приложением, поскольку все приложение находится на одной веб-странице. Каждое угловое представление обычно содержится в теге div или section, но не на его собственной веб-странице.
borja gómez 03 июль 2015, в 13:43
0

Хорошо, я понял. Так быстро ли происходит беспорядок для обмена информацией или запуска событий между контроллерами?
Yohan Béjannin 03 июль 2015, в 13:55
0

Нет, не должно быть. Вы можете обмениваться информацией между первичными контроллерами, передавая аргументы в строке запроса или используя службу Angular. И с событиями из коробки Angular предоставляет механизм: $ rootScope. $ Emit, $ rootScope. $ Broadcast, $ rootScope. $ On Но вы можете легко использовать другие, например, [pubsubjs] ( github.com/mroderick/PubSubJS )
borja gómez 03 июль 2015, в 14:02

Показать ещё 2 комментария

Ещё вопросы

Спасибо за Ваш ответ. Что вы подразумеваете под одним объектом окна? У меня может быть меню с несколькими различными страницами (список A, список B, например), все в одном приложении Angular. Вероятно, у меня будет один контроллер на странице, но только одно приложение Angular. Не так ли?
Да, у вас есть столько контроллеров, сколько вы хотите, и вы можете перемещаться между ними, но вся навигация происходит внутри одного и того же оконного объекта, поэтому он называется одностраничным приложением, поскольку все приложение находится на одной веб-странице. Каждое угловое представление обычно содержится в теге div или section, но не на его собственной веб-странице.
Хорошо, я понял. Так быстро ли происходит беспорядок для обмена информацией или запуска событий между контроллерами?
Нет, не должно быть. Вы можете обмениваться информацией между первичными контроллерами, передавая аргументы в строке запроса или используя службу Angular. И с событиями из коробки Angular предоставляет механизм: $ rootScope. $ Emit, $ rootScope. $ Broadcast, $ rootScope. $ On Но вы можете легко использовать другие, например, [pubsubjs] ( github.com/mroderick/PubSubJS )

mikeswright49 · Accepted Answer · 2015-07-03T11-59-00.000Z

Я лично делал вариации ряда угловых приложений, варьируя от SPA с представлениями 50K+ до простого использования углового в качестве расширения базового javascript для полезного тестирования и модуляции.

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

Важные вопросы:

Удобна ли ваша команда в Rails или Angular
Насколько динамичны ваши веб-страницы
Какие браузеры вы поддерживаете?
Существует ли требование для задержки данных и связи с сервером
Вы также собираетесь повторно использовать API-интерфейс сервера для других приложений

Эти вопросы помогут вам использовать Angular или Rails или комбинацию технологий для поиска баланса.

Привет спасибо за ответ Таким образом, по вашему мнению, полный интерфейсный AngularJS не является проблемным событием, если приложение многостраничное, и не будет проблемой, если оно станет больше в будущем. Основная идея состоит в том, чтобы повторно использовать API для другой системы, поэтому я хочу, чтобы он был независимым с самого начала.
Это правильно. Правильно спроектированный SPA с оптимизацией доставки может очень легко масштабироваться до сотен «страниц» и просмотров. Если вы идете по этому пути, пожалуйста, используйте require и их инструменты связывания и минимизации, иначе вы будете иметь ужасную производительность по мере роста приложения.
Есть ли у вас какие-либо ссылки, касающиеся этих «требуемых и их инструментов для объединения и минимизации»?
requirejs.org Это отображение зависимости между файлами javascript. Это также сделает пакетирование и минификацию для вас. В моем последнем проекте он сложил более 100 файлов на 3 и перешел с 3 МБ до 40 КБ. Без этого проект был бы невозможен.