Веб-сайты AngularJS: отдельные SPA и несколько приложений/компонентов SPA

Этот вопрос прослушивал меня уже некоторое время.

Если вы создаете веб-сайт с множеством функций, используя Angular, лучше ли создавать огромный SPA или разбивать веб-сайт на функциональные "приложения" и создавать SPA для каждого приложения?

Например, у нас есть сайт для социальных сетей с лентой уведомлений, профилем пользователя, отчетами и группами. Собираете ли вы все эти функции в единый SPA или создаете 4 разных SPA и позволяете базовому пути маршрута к правильному SPA?

например.

www.mywebsite.foo #/Профиль/12345/образование

против

www.mywebsite.foo/profile/12345#/education

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

ОТВЕТЫ

Ответ 1

Марк Коллингс говорил о вашей статье:

https://markwillcollins.silvrback.com/7-things-i-wish-i-knew-about-angularjs

"3. Структура критическая..."

Он предлагает планировать каждую страницу перед началом работы.

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

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

Ответ 2

Итак, вот что я узнал и что я сделал:

Мой сервер имеет маршрут по умолчанию:

  var express = require('express');
  var router = express.Router();

  ... 

  router.get('*', function(req, res) {
    res.sendfile(path.resolve(__dirname + '/../../../build/index.html')); // Send index.html for HTML5Mode
  });

  return router;

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

Что принадлежит одному SPA?

Все состояние, которое взаимосвязано в пользовательском интерфейсе. Будет сложно разделить состояние между приложениями (например, проверку подлинности). Конечно, они могут получить доступ к полному состоянию вашего сервера.

Когда это полезно?

Если у вас есть макеты, которые показывают явно разные варианты использования, например. два вида пользователей с разными логинами. Или два разных "места", в которые они вошли.

Что нужно получить?

  • Если приложение "панель инструментов" загружает кучу графического кода, но приложение "целевая страница" не нуждается в нем, вы можете сделать лучший опыт для конечных пользователей.
  • Если пользователь испытывает разные ситуации, легче хранить другой код в разных местах.
  • В моем случае на сервере были также созданы преимущества SEO-рендеринга шаблонов целевой страницы.

Возможно, вы не знаете, что вам действительно нужно, пока не попробуете. Поэтому я рекомендую собирать все, что зависит от входа в одно приложение. И приложение по умолчанию должно включать "анонимный посетитель".