Pull to refresh

Comments 23

redux-actions покраше будут этих switch типов

Сейчас стремительно набирают популярность решения типа Create React App, которые постулируют подход «ноль конфигурации», все ставится одной командой, работает прямо из коробки, но содержит кучу ограничений, к тому же серверным рендерингом не обладает совсем.

Никто не мешает импортнуть конфиг приложения и добавить буквально пару строчек для всего, что надо. Просто из коробки, там действительно 0 конфигурации и хватает вполне себе большенству проектов
Более того серверсайд рендеринг попросту никак не ограничивается Create React App.
Он есть из коробки? Нет. Рассматривается исключительно стандартная поставка. Любые навороты сверху я лучше буду делать с полным контролем, зачем мне Create React App для этого? Или возьму другой фреймворк.

Меня коробит ощущение, что в Next.js получается очередной монолит. Проходили в Meteor-е.

Попробуйте Electode от Walmart Labs, там подход другой. Next тоже по-своему прекрасен.
Да кстате, уж слишком много своего навязывается.
Бредовый подход. Я лучше возьму более кастомизированный инструмент чем монолитное гуано которое едвали рассширяется.
Что там делать того ssr? Подготовить стор под redux на серваке? Боже ну это просто непосильная задача
буду делать с полным контролем

Или возьму другой фреймворк.

Это все звучит, но в вашем случае это скорее — я не разобрался как написать 2 строчки с create-react-app, и просто нашел жирный фреймворк ради ssr
Все к нему прикручивается, только не в 2 строчки, вот пример, как на моей же миддлваре это можно сделать. Сайты делают разные люди, а не только Вы или я, не все хотят знать, как оно работает изнутри.
А в Create React App много возникает трудностей если самому прикрутить серверный рендеринг если он из коробки не поддерживется или лучше уже сразу использовать уже готовое решение Next.js, Electrode если наперед знаешь что потребуется изоморфизм.
Смотря как прикручивать. Для него есть react snapshot пакет, который делает статический сайт, обходя все ссылки. Но оно не работает с Redux. Есть моя миддлвара для Router + Redux, с ней хлопот не очень много, но продукт относительно свежий, хоть и крутящийся на продакшене. Next/Electrode более матерые, но и ограничений там порядком. Попробуйте сами разные варианты, быстро станет очевидно, какой Вам больше подходит.

Может у вас есть на примете готовое решение для SSR?

Для тех, кому данный подход понравился, спешу огорчить (хоть и с лагом в три года, лол). Как видно из 2021-ого это, к сожалению, похоже, тупиковый подход.

В документации самого Next.js советуют не использовать getInitialProps. И, судя по обсуждениям на гитхабе, ещё через пару версий getInitialProps и вовсе может стать depricated.

Ага, они вместо устаревшего getInitialProps ввели два getStaticProps и getServerSideProps. Описанная выше библиотека все это поддерживает. В чем тупиковость?

Тупиковость в том, что для реализации доступа к хранилищу из getServerSideProps достаточно чуть-чуть модифицировать файл в котором создаётся store и просто импортировать экземпляр хранилища напрямую из этого файла, ставить дополнительную либу особого смысла нет.

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

Это не так, все гораздо сложнее, т.к. store надо правильно гидрировать, не пересоздавать стор на переходах страниц и тд. Посмотрите код библиотеки, там много edge cases которые вы будете решать самостоятельно, и по сути просто перепишете ее заново.


На данный момент годы идут, все продукты развиваются и библиотека развивается вместе с ними. Если вас смущает vendor lock — не пользуйтесь, но вы тогда останетесь со всеми проблемами один на один. Если по такой логике действовать — то вы ни одну библиотеку не должны использовать. Ни next, ни redux. А чтоб подлить масла в огонь еще грядут server side components в самом реакте.

А зачем переходить по страницам во время рендеринга страницы на сервере?

Если в приложении есть такой кейс, значит что-то не так с архитектурой.

Не пользуйтесь, но вы тогда останетесь со всеми проблемами один на один

Так это как раз и случится, как только next и redux выкатят какую-нибудь новую версию, а у указанной либы её поддержки не будет до тех пор пока левая пятка мэйнтейнеров не захочет это исправить. В случае когда проблема решается своими силами — можно хотя бы решить проблему самостоятельно. А иначе весь код будет завязан на стороннее решение.

Если по такой логике действовать — то вы ни одну библиотеку не должны использовать.

Тут вы ошибаетесь. Next и Redux это основной костяк системы. Если работа с ними будет осуществляться через стороннее решение — всё завязывается, условно, на одну проблемную точку, которая поддерживается неизвестно кем и неизвестно сколько будет поддерживаться в дальнейшем. Когда сторонние библиотеки используются для какой-то вспомогательной мелочи, проблемный код всегда можно переписать, а в случае Next+Redux переписать придётся большую часть кода.

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

Вы, очевидно, не понимаете механизм работы. Пользователь зашел на страницу, она отрендерилась на сервере, redux state был доставлен на клиент, пользователь взаимодействует со страницей, меняя стейт, и затем уходит на другую страницу, которая тоже рендерится на сервере, новый стейт с сервера нужно правильно объединить с клиентским.


до тех пор пока левая пятка мэйнтейнеров не захочет это исправить

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


я считаю что сторонние библиотеки, влияющие на архитектуру нужно привлекать с крайней осмотрительностью

И Next и Redux тоже когда то были значительно менее распространены. У библиотеки сейчас 11 тыс использований и 105 тыс скачиваний в неделю, люди активно пользуются и довольны. Повторяю, не хотите — не используйте, пишите все сами. Авторы Next в каждом релизе вносят что-то несовместимое со старым, это по-вашему тоже опасная завязка и тупиковый путь?

Пользователь зашел на страницу, она отрендерилась на сервере, redux state был доставлен на клиент, пользователь взаимодействует со страницей, меняя стейт, и затем уходит на другую страницу, которая тоже рендерится на сервере, новый стейт с сервера нужно правильно объединить с клиентским.

Ну, то есть, это актуально для архитектуры, в которой каждая страница всегда рендерится на сервере. В таком случае (опять же, это, конечно, лишь мой взгляд на вещи) это как раз корявая архитектура. SPA на то и SPA, что на сервере должен происходить лишь первый рендеринг, а при переходе на другие страницы рендер должен лежать на клиенте, тогда и стейт передавать на сервер нет необходимости.

Но, я, конечно, понимаю, что вариантов построения приложения множество и такой вариант тоже имеет место…

Авторы Next в каждом релизе вносят что-то несовместимое со старым, это по-вашему тоже опасная завязка и тупиковый путь?

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

А как у вас реализована поддержка getServerSideProps? Вы оборачиваете App в свой HOC?
SPA на то и SPA, что на сервере должен происходить лишь первый рендеринг

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


рендер должен лежать на клиенте

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


Если бы вас там была целая компания, которая заточена на разработку этой либы

Вам не угодишь. Повторюсь, библиотека решает проблемы, люди пользуются и довольны. Вам не нравится — не пользуйтесь.


А как у вас реализована поддержка getServerSideProps? Вы оборачиваете App в свой HOC?

https://github.com/kirill-konshin/next-redux-wrapper#getserversideprops через HOC + обертку для getServerSideProps

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

Эдак мы с вами в вопросы идеологии упрёмся… Если каждую вторую страницу рендерить на сервере и передавать состояние хранилища при переходе по страницам, то при росте стора рано или поздно это всё превратится в тормозного монстра, нивелирующего все плюсы SSR. Ну или, например, может понадобиться на стороне сервера стучаться в какие-то сторонние API и тогда переход на такую страницу мало того что будет гимором с точки зрения необходимости гидрации стора, так ещё происходить этот переход будет медленно — тогда смысл в SPA и Next вообще?

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

github.com/kirill-konshin/next-redux-wrapper#getserversideprops через HOC + обертку для getServerSideProps

Вы не поняли, документацию я видел. Меня больше интересует как вы это реализовали «под капотом». Я понимаю, что у вас весь код открыт, но раз есть возможность попросить у разработчика напрямую объяснить на пальцах, это всегда удобнее. К тому же, я так думаю это не мне одному может быть полезно.
Пардон, не обратил сразу внимания на Wrapper. Теперь чуть понятнее.
Про getServerSideProps я спрашиваю, потому что везде в статье речь идёт про getInitialProps, и как добавить в его аргументы свой стор я +\- понимаю, а вот как оно работает в случае getServerSideProps, я не понимаю, учитывая, что в документации к нексту инфы как это сделать не найти.
Only those users with full accounts are able to leave comments. Log in, please.

Articles