Комментарии 3
У меня иногда возникает ощущение, будто некоторые статьи специально раздуваются до конских размеров, будто это повышает качество материала.Но нет. Вместо того чтоб расписывать то, что и так отлично расписано в документации проекта (а это, я думаю, около половины того что вы тут написали), лучше бы подробнее описали баги и косяки этого фреймворка. Как минимум, в этом есть смысл ещё и потому что документация проекта меняется постоянно, т.к. фреймворк активно дорабатывается. Т.е. часть написанного может стать бесполезна уже через полгода-год. А вот баги порой кочуют из версии в версию.
А проблем у фреймворка хватает. По сути, единственное для чего разумно использовать Next это либо малые приложения на несколько страниц (не стоит оно того), либо приложения среднего размера, с относительно простой архитектурой, которую представляется возможным продумать полностью до того как начнёшь её писать. Большой же проект неизбежно столкнётся с проблемами и багами которые непонятно как исправить (в код фреймворка же не полезешь), а кроме того, есть риск что придётся постоянно переписывать приложение чтоб оно нормально работало, потому что практики, изложенные в документации, которые вы начнёте использовать, уже через полгода изменят на какой-нибудь новый подход (это камень в огород data fetching, где раньше фигурировал, например, метод getInitialProps, а в какой-то момент он стал deprecated, причём не просто deprecated, а буквально пришлось всё переписвывать). Вообще я гораздо больше конкретных проблем бы мог описать, если бы все их записывал, но увы, мне было не до заметок, а память не резиновая. По этой причине хочу отметить однозначно плохие практики, которые доставили лично мне больше всего проблем:
Если ваше приложение требует общего хранилища данных, то я не бы не стал использовать Redux. К примеру, в 10.х версии NextJS буквально единственным вариантом оптимального использования Next c редаксом был next-redux-wrapper (сами разработчики его и советуют в общем-то). Вот только и он глючит в некоторых кейсах при работе с SSR, причём глюки абсолютно необъяснимые. Также, при использовании Redux в компонентах, если вам помимо компонентов нужны данные из стора также в каком-нибудь хелпере (вне компонента) возникает проблема неконсистентности стора и я не представляю как её решать с помощью Next. Короче с этим фреймворком я вообще не стал бы использовать какие-то библиотеки управления состоянием... может быть разве что mobx, но я всё-таки не думаю что это хорошая идея, лучше обойтись без хранилища, например постараться использовать useContext для хранения состояния, если это возможно.
Я не знаю что на выходе даёт
create-next-app, однако я пользовался старым бойлерплейтом для Next от Vercel, который сейчас уже не поддерживается. Так вот на основе опыта работы с тем бойлерплейтом, я бы посоветовал вообще не пользоваться подобными штуками, а всё-таки собирать проект с нуля самостоятельно. Причин тому достаточно много, начиная с того что может внезапно оказаться крайне времязатратно перейти на желаемую версию какого-либо модуля (в моём случае сложность возникла с обновлением webpack), что затем влечёт за собой также обновление половины пакетов, практически полное переписывание конфигов и т.д.
Полезная статья. Спасибо!
Мнение новичка в современном front-end в целом и Next.js в частности.
Эта статья, по сути, перевод документации с официального сайта фреймворка. Только без удобной навигации по разделам и ссылок на репозитории Github с примерами. Зачем, для чего? Людям вроде меня с месяц назад это не поможет от слова совсем.
К тому же, опущено и (или) не раскрыто множество деталей (а дьявол, как известно, в них). Например, почему нужно "обращать внимание" на структуру paths? Почему нет комментария из официального обучающего курса, что представленная структура обязательна? Как именно взаимодействуют между собой функции getStaticPaths и getStaticProps? Почему именно в таком порядке?
Next.js: подробное руководство. Итерация первая