Удобный интерфейс в NextJS

Недавно я решил поэкспериментировать с NextJS как с способом реализации React-интерфейса для Kushy. В настоящее время Kushy работает напрямую с Laravel, а не как отдельное приложение, использующее Laravel API. Я хотел углубиться в React с Kushy, но было трудно найти фреймворк, который правильно масштабируется, и я избегал делать это с нуля (создавая собственную конфигурацию Webpack, маршрут и разделение CSS, все этот джаз).

Цель этого эксперимента состояла в том, чтобы создать приложение NextJS для Kushy с использованием Kushy API и выяснить, что нужно для примерного создания некоторых базовых функций Kushy (просмотр отдельных предприятий по слизням).

Пример

Вы можете проверить проект, развернутый на Heroku, или просмотреть исходный код на Github:

Проблемы

При попытке использовать NextJS я сразу же столкнулся с парой проблем. К счастью, только парочка.

Динамическая маршрутизация (/posts/{slug})

NextJS не имеет этого из коробки. Вам нужно создать сервер NodeJS (в данном случае Express) с вашими динамическими маршрутами.

См.: Документация NextJS по пользовательскому серверу/маршрутизации, эта статья, этот плагин,

В итоге использовал плагин (https://www.npmjs.com/package/next-routes), чтобы сделать это легко. В будущем я буду использовать только Express API.

Развертывание

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

npm run build npm run start

Делает NextJS идеальным для чего-то вроде Heroku, который обрабатывает этот процесс. А может и нет, если у них нет проксирования/несколько экземпляров — поскольку NextJS лучше всего работает в кластере.

Можно запустить процесс статической сборки, такой как GatsbyJS, который может работать на CDN/узле, таком как Github Pages или Netlify. Но вы теряете динамическую маршрутизацию и SSR, которые предоставляют Node и Express. Вот где GatsbyJS сияет, он извлекает весь контент, чтобы жить статически, в то время как NextJS извлекает по запросу.

Вход пользователя/авторизация

NextJS не имеет встроенных функций для «защищенных» маршрутов, если вам нужно заблокировать определенные страницы после аутентификации входа. К счастью, с тем, как NextJS работает на стороне сервера и на стороне клиента, это было несложно.

Чтобы войти в систему, я использовал API, использующий поток OAuth2.0, поэтому я перенаправил пользователя на логин API. Как только пользователь вошел в систему и одобрил приложение, он перенаправляется обратно на страницу обратного вызова в приложении. Эта страница делает последний запрос к API (используя секретный токен, который API отправляет в обратный вызов), и API в последний раз отвечает токеном доступа или JWT (веб-токен JSON) для пользователя.

Вот где проявляется магия NextJS. Мы храним токен в файле cookie на стороне сервера, что позволяет нам получить его из любого места (сервера или клиента). Когда нам нужен токен, мы анализируем его из заголовков на стороне сервера (пропущенных через метод getInitialProps()) или используем библиотеку, например js-cookie, для получения файлов cookie на стороне клиента.

Чтобы создать защищенный маршрут, вы создаете HOC, который проверяет cookie в жизненных циклах getInitialProps() и componentDidMount(). Если вы найдете файл cookie маркера, HOC загружает компонент страницы. Но если он не может найти файл cookie, он перенаправляет пользователя на общедоступную страницу (обычно это логин).

Вывод

Как и в случае с любым хорошим фреймворком, когда вы знаете, что делаете — и понимаете, как он обрабатывает определенные вещи — становится легко создавать то, что вы хотите. Я ушел от работы над NextJS с мыслями о нескольких приложениях, которые я мог вытащить сейчас, когда я мог их применить. Хотя я не уверен, что это будет тот фреймворк, который мы будем использовать для фронтенда Kushy, это определенно отличный претендент.

Канпай 🍻
Рё

Ссылки:

Первоначально опубликовано на whoisryosuke.com.