В общем, еще одна проблема, и, вероятно, причина, почему серверный контекст в текущей реализации next не имеет смысла: next рендерит дерево снизу вверх, то есть сначала вложенные страницы, затем вложенные лейауты, затем лейаут выше и т.д. Подробнее: https://github.com/vercel/next.js/discussions/53026
В общем, мне кажется, я понял логику команды Nextjs: вам не нужен серверный контекст, потому что мы сделали кеширование для fetch. Пример: нужно рендерить что-то в зависимости от авторизации? Создайте api/user и делайте запрос getUser() во всех своих компонентах, где нужно получить эти данные. Потому что они будут из кеша.
Хорошо это или плохо я пока не понял... С одной стороны, в рамках рект-логики это непривычно, с другой стороны, в рамках чисто серверных приложений, такой подход живет, где у нас вместо fetch запроса запрос к бд, например.
Нашел еще крутой use case: i18n. Для переводов необходим контекст, иначе придется прокидывать все в пропсы. То есть без единого контекста в клиентских файлах, которые отрендерит сервер, не будет перевода, а будет заглушка типо header.chat.title и только позже подхватится на клиенте, но прилетит content did not match . Я пока так и не придумал как это обойти.
Тоже непонятен этот подход, какой-то странный hydrate получается, когда при серверном рендеринге куска просто нет =) Вместо Layout можно использовать Template, он как раз обновляется при переходах. Вот такой провайдер не получится сделать, при компиляции клиентской части не найдет async_hooks, да и useContext должен быть разный. То есть в идеале концепция одна Context provider + useContext, на серверной стороне это будет через async_hooks, а на клиентской через react.
Выглядит мега полезно, возникает вопрос, почему не было этого из коробки и почему они не принимают PR. Еще вопрос, как это срастить с клиентским контекстом. Было бы здорово собрать все на серваке с серверным контекстом, а потом, на клиенте, поменять его. Например: Проверка авторизации и рендер в зависимости от наличия авторизации и/или прав
Ох, сколько политоты в комментах. Если откровенно:
Сайт шикарен, прекрасная работа, за такой объем работы цена не высока (я думаю, там под катом еще куча фишек, которые мы не увидели).
Придираться можно сколько угодно, но вышло отлично.
вот чего откопал в var/www/log/nginx.error.log, содержимое следующее (повторяется)
2015/03/04 07:35:59 [crit] 279#0: *12 connect() to unix:/var/www/application/current/tmp/sockets/.unicorn.sock failed (2: No such file or directory) while connecting to upstream, client: 94.230.122.71, server: _, request: «GET / HTTP/1.1», upstream: «unix:/var/www/application/current/tmp/socke...», host: "...."
День добрый.
Сервер настроен, благодарю. Приложение задеплойжено.
Но возникла проблема «We're sorry, but something went wrong.»
Ассеты прекп-л, с дб сконектился.
Никак не могу понять в чем проблема, уже несколько дней бьюсь.
Спасибо. Завтра завершу деплой.
И еще вопрос, какие хорошие ресурсы/книги есть по данному вопросу (кроме, Ruby on Rails Tutorial`a Хартла и раилс каст )?
Благодарен за помощь.
Где находится gemfile в моем приложении, хвала Одину, я знаю. Но на сервере его еще нет, ведь я еще его не деплоил. Или я ставлю unicorn на локальный комп с которого деплою?
Так, уважаемые. За последние несколько дней я познакомился очень близко, повозясь лицом по клаве, с консолью, ssh доступом, ubuntu и т.д.
Поборол саппорт VPS и дошел таки до установки Unicorn, но никак не могу найти где же gemfile.
Да, скорее всего я туплю, но нервы мои на исходе, сижу уже много часов надо всем этим.
Самое тяжелое в разработке — оказалось деплоить приложение. Так что, прошу, знатоки, окажите поддержку.
Извиняюсь за предыдущий комментарий.
Даже объяснив ребенку, что такое мороженое и шоколад — он может не знать, чего он хочет. А чаще — хотеть всего и сразу.
Как-то, как мне кажется, это все по-детски, слабо и бесхарактерно. Лишь отмазки и т.п. Разве можно так чего-то достигнуть?
Для меня всегда было очевидным: есть проблема — надо решить.
Почему многие этого не понимают я не знаю. Точнее, они наверное понимают, но делать этого не хотят.
В общем, еще одна проблема, и, вероятно, причина, почему серверный контекст в текущей реализации next не имеет смысла: next рендерит дерево снизу вверх, то есть сначала вложенные страницы, затем вложенные лейауты, затем лейаут выше и т.д. Подробнее: https://github.com/vercel/next.js/discussions/53026
В общем, мне кажется, я понял логику команды Nextjs: вам не нужен серверный контекст, потому что мы сделали кеширование для fetch. Пример: нужно рендерить что-то в зависимости от авторизации? Создайте api/user и делайте запрос
getUser()во всех своих компонентах, где нужно получить эти данные. Потому что они будут из кеша.Хорошо это или плохо я пока не понял...
С одной стороны, в рамках рект-логики это непривычно, с другой стороны, в рамках чисто серверных приложений, такой подход живет, где у нас вместо fetch запроса запрос к бд, например.
Так, тут я затупил, обычные контексты работают же в SSR, если это клиентский компонент
Попробовал геттер в темплейте, компонент обновляется, но вот pathname остается тот же... то есть компонент просто ремаунтится =(
Нашел еще крутой use case: i18n. Для переводов необходим контекст, иначе придется прокидывать все в пропсы. То есть без единого контекста в клиентских файлах, которые отрендерит сервер, не будет перевода, а будет заглушка типо
header.chat.titleи только позже подхватится на клиенте, но прилетитcontent did not match. Я пока так и не придумал как это обойти.Тоже непонятен этот подход, какой-то странный hydrate получается, когда при серверном рендеринге куска просто нет =)
Вместо Layout можно использовать Template, он как раз обновляется при переходах.
Вот такой провайдер не получится сделать, при компиляции клиентской части не найдет async_hooks, да и useContext должен быть разный. То есть в идеале концепция одна Context provider + useContext, на серверной стороне это будет через async_hooks, а на клиентской через react.
Выглядит мега полезно, возникает вопрос, почему не было этого из коробки и почему они не принимают PR.
Еще вопрос, как это срастить с клиентским контекстом. Было бы здорово собрать все на серваке с серверным контекстом, а потом, на клиенте, поменять его. Например:
Проверка авторизации и рендер в зависимости от наличия авторизации и/или прав
Согласен, бой/боевой (в роли сервера) - отлично смотрится. При желании можно найти вполне удачные альтернативы многим терминам, но это никому не надо.
Сайт шикарен, прекрасная работа, за такой объем работы цена не высока (я думаю, там под катом еще куча фишек, которые мы не увидели).
Придираться можно сколько угодно, но вышло отлично.
2015/03/04 07:35:59 [crit] 279#0: *12 connect() to unix:/var/www/application/current/tmp/sockets/.unicorn.sock failed (2: No such file or directory) while connecting to upstream, client: 94.230.122.71, server: _, request: «GET / HTTP/1.1», upstream: «unix:/var/www/application/current/tmp/socke...», host: "...."
Сервер настроен, благодарю. Приложение задеплойжено.
Но возникла проблема «We're sorry, but something went wrong.»
Ассеты прекп-л, с дб сконектился.
Никак не могу понять в чем проблема, уже несколько дней бьюсь.
И еще вопрос, какие хорошие ресурсы/книги есть по данному вопросу (кроме, Ruby on Rails Tutorial`a Хартла и раилс каст )?
Благодарен за помощь.
Поборол саппорт VPS и дошел таки до установки Unicorn, но никак не могу найти где же gemfile.
Да, скорее всего я туплю, но нервы мои на исходе, сижу уже много часов надо всем этим.
Самое тяжелое в разработке — оказалось деплоить приложение. Так что, прошу, знатоки, окажите поддержку.
Даже объяснив ребенку, что такое мороженое и шоколад — он может не знать, чего он хочет. А чаще — хотеть всего и сразу.
Для меня всегда было очевидным: есть проблема — надо решить.
Почему многие этого не понимают я не знаю. Точнее, они наверное понимают, но делать этого не хотят.