Ограничения статического рендеринга при доставке вошедших в систему событий на конечные точки без аутентификации - PullRequest
0 голосов
/ 05 января 2019

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

Проблема заключается в следующем: возможно ли обеспечить несколько иные возможности для одних и тех же URL-адресов в зависимости от того, вошли вы в систему или нет?

Возьмите, к примеру, https://github.com/gatsbyjs/gatsby. Если вы вышли из системы, вы увидите кнопку, которая помечает репозиторий. Однако, когда вы вошли в систему и пометили ее, вы увидите «Unstar».

И, глядя на источник, он, похоже, находится в начальной загрузке с сервера.

Но для того, чтобы это работало, вам нужен сервер, который может 1.) определить, вошли ли вы в систему и 2.) на основе вашего профиля / предпочтений / данных отобразить определенный контент.

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

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

Я что-то здесь упускаю или это просто ограничение технологии?

1 Ответ

0 голосов
/ 05 января 2019

Как правило, вы хотите обслуживать сайт для аутентифицированных пользователей через сервисного работника, так как тогда он может быстро выполнить первоначальный пользовательский рендеринг для пользователя. Этот шаблон часто называют App Shell Model https://developers.google.com/web/fundamentals/architecture/app-shell

...