Ничего не страшно, что не ломается.

Ну иногда может не ломаться, но перформанс при смерти будет

Думаю теряется смысл в SSR если на стороне клиента буду менять   DOM, через InitialProps все прошло нормально и ошибка пропала, спасибо.

добавь логику вывода чарта через дидмаунт/эффект и будет тебе магия

Вчера на радость Максу и попугаю был уже в полшаге от отказа от редакса, но как подумал сколько props-drilling штук будет, в итоге не стал. В промис обернул изменения в редаксе для показа 404. Заодно сделал синглтон для проброса авторизационной куки

Что за синглтон для куки?

Сделал класс в котором два метода, один с п̶и̶к̶а̶м̶и̶ ̶т̶о̶ч̶ё̶н̶ы̶м̶и̶ setContext, который надо вызывать в gip с контекстом в качестве аргумента, а второй - fetch, который насыщается куками в headers, которые установились в класс первым методом

и зачем ты это сделал? ну рили не понимаю ((( ведь куки ведь довольно прямой апи (получить, записать, удалить). Создавать синглтон только ради дублирования методов апи?

Ты какое то другое сообщение читал? По моему я про другое говорил. Смотри - есть бэк на питоне, там сессии, авторизация, работа с бд, кеширование. Без ssr - все гладко, браузер автоматом (на самом деле когда установлен заголовок credintials: "include") прикрепляет в заголовки еще и Cookie заголовок. Так бэк понимает что пользователь авторизован. Но с SSR куку надо брать из req в случае если запрос делается со стороны nodejs, НО! по прежнему брать куку из document.cookie если запрос делается с клиента. Так как gip отрабатывает и с той и с другой стороны, нужно по разному доставать куку. В моем случае каждый запрос должен содержать авторизацию, так как от нее много зависит на каждом из этапов работы с апи.
1 вариант (как было): в gip проверяем серверный он или клиентский, в зависимости от этого по-разному выковыриваем куку. Эту куку скармливаем функции которая сделает запрос в апи с заголовками содержащими полученную в gip куку. Хорошо когда нет редакса и fetch делается не посредственно в gip.  Но увы, у это не мой случай, мне приходилось класть куку в payload action-creator'а, чтоб далее в саге дернуть fetch с этим заголовком. Согласись - дичь полная, каждый раз выковыривать эту куку в gip, копипастить код, следить чтоб в экшн провалились все нужные аргументы, на забыть в каждой саге передать эти аргументы (заголовки) в запрос.
2 вариант (как стало): Класс, у которого есть два метода: setContext (вот тут, я полгаю ты долбился в глаза, раз перепутал это с установкой куки). Этот метод нужно просто вызывать в каждом gip где будет диспачнут экшн который тригерит сагу, ходящую в апи. Он кладет текущий контекст в свойство класса. И второй метод - ПРОСТО FETCH который из своего свойства, который установлен был первым методом берет куку (или берет ее из document.cookie, если запрос из браузера делается) и насыщает fetch этим заголовком. А саги и редакс и экшены вообще теперь не нуждаются в пробросе загловков от gip до самых саг и реквестов, потому что каждый реквест сделан не fetch, а МОЙСИНГЛТОН.fetch

Ок. Я не хотел тебя обидеть

ладно, прощаю

вообще вот вся магия

в примере в репе Next.js with-cookie написана какая то дичь, которая работает в хэллоу ворлдах и не масштабируется совершенно

Почему?

так написали ее

zeit/next.js
Pre-release v9.2.2-canary.19
### Patches

- Add global CSS styles to example/with-stripe-typescript: #10520
- Remove native-url Again: #10526

### Credits

Huge thanks to @thorsten-stripe for helping!

Дрил идёт лесом же в случае контекстов)

А что ты тут исправлял? А то очень похоже что у нас одна и та же проблема была

Это как раз новье, тут уже все ок работает, по крайней мере пока багов не обнаружил. Там выше от меня сообщение, первый способ описанный там - это как было у меня. Скриншот - как стало.

Прочёл - это тебе создаст баг - такой синглтон