Обсыпка в каркас



Я прочитал несколько сообщений о переполнении стека, в которых спрашивалось, как использовать Angular вместе с клиентской структурой на стороне сервера, такой как Asp.Net Core MVC. Многие из этих вопросов исходят от людей, которые просто хотят предоставить расширенный пользовательский интерфейс для определенной функции в своем приложении .Net MVC. Термины, которые часто используются для описания этого сценария, - это мини-SPA или гибридный SPA. К сожалению, во многих ответах предлагается не использовать фреймворк, такой как Angular, вместе с другим фреймворком на стороне сервера. Я хотел бы поделиться подходом, который мне подходит.

На диаграмме ниже показан подход на высоком уровне.

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

Я чувствую, что, не заменяя мою серверную структуру полностью клиентской, моя клиентская часть кода значительно упрощается. Много кода, связанного с инфраструктурой, также перемещено из моего приложения SPA и обратно на серверную часть, где оно и принадлежит. Итак, давайте посмотрим на ключевые компоненты этого подхода.

Модули функций

При таком подходе я удостоверяюсь, что к каждому мини-спа можно получить доступ после хорошего «старомодного» полного обновления страницы. Затем сервер извлекает данные из бэкэнда, предварительно загружает данные в представление и отображает простую HTML-страницу, содержащую тег компонента приложения и связанные зависимости сценария.

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

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

Предварительная загрузка функциональных модулей

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

Затем я могу получить доступ к этим предварительно загруженным данным в компоненте контейнера моей функции или где угодно в моем мини-спа.

Мне также нужен был способ динамически вставлять скрипты приложений, сгенерированные angular-cli, в мои страницы razor. Поэтому я решил создать простое вспомогательное расширение html, которое просто считывает файл index.html из папки dist.

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

Просто резюмирую. Этот пост не задумывался как пошаговое руководство по использованию Angular с Net Core MVC, и я не считаю это «правильным способом» совместного использования двух фреймворков. Я просто хотел поделиться подходом, который у меня был успешным, и я надеюсь, что он поможет вам добиться успеха в будущем проекте.