NextJS, первый взгляд

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

На первый взгляд все оказалось очень круто, что интересно, почему-то даже некоторые интерактивные элементы начали работать быстрее, не разбирался пока, какая магия их ускорила, но не отметить не мог. Миграция тоже прошла гладко, подключение к проекту было самым крутым из всех инструментов: установить через yarn, удалить конфиг webpack’а, - именно последний пункт больше всего понравился.

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

Казалось бы, роутинг должен быть сильнее всего проработан в фреймворке такого типа, но то ли я не понял, как им правильно пользоваться, то ли оно как-то странно сделано. Ладно, со ссылками пришлось повозиться, ибо в одном случае href - тот url, на который непосредственно идет редирект, а в другом случае - slug страницы, который я определил в роутере, а непосредственно ссылку прокидывать нужно в проп as.

Но вот если пушить что-то в url с динамическим роутом, то получается что-то странное. Пушу не явный конечный url, а slug описанный в роутинге, нужна квери-стринга? Ок, квери можно прокинуть в отдельный объект, они даже до чилда долетят, но вот в url они не попадут, бери ручками и прокидывай.

Тут у меня прямо явный диссонанс:

  • Ожидание: сейчас я в метод пуш прокину объект квери и текущий адрес - хоба, квери обновлен, строка адреса хранит состояние, все счастливы.
  • Реальность: прокидываю реальный адрес, прокидываю шаблон адреса, прокидываю квери-объект, новый полный адрес вместе с квери, который сам леплю чем-то, - тоже все счастливы, конечно, но большей ценой.

Действий немного, но хотелось бы каких-то изящных абстракций из коробки, а не руками их делать.

Published

# ReactJS, SEO, JavaScript, NextJS

© Igor Fedyukin 2009 - 2020