Спасибо большое, видимо, отсутствие опыта с react сказывается. Думал про всякие динамически импорты и тому подобное, но просто сделать обертку не додумался. Единственное, что использовал контекст в root layout чтобы все используемые в проекте компоненты могли использовать, т.к. это глобальная фича.
Подсажите еще, пожалуйста, зачем разделять UserDeviceContext и SetUserDeviceContext ? Для того, чтобы уменшить вляние ререндеринга при измении любой из пропертей контекста и вместо этого пользоваться мемозацией примитивов?
А чем Вам не нравится режим серверного рендеринга?
Стили не всегда могут помочь. Самый базовй пример, у меня есть компонент кнопки. Пропсами в него передаются тип и размер. Т.е. для того, чтобы поменять размер кнопки с md на sm мне нужно изменить инпут параметр. Соответственно при перезагрузке страницы, когда серварная часть возвращает уже готовый html мне нужно знать мобильная версия или нет. И если компонент помечен как client, то mediaQuery отработает только в браузере, и кнопка поменяет размер.
Такая же проблема с изменением количества столбцов в masonry layout. У нас есть кнопка тригер, которая меняет кол-во столбцов, плюс разные возможные значения для мобильной и десктопных версий. Т.е. контролируется это через код, а не стили. Вот и получается, что в клинтском компоненте (при начальном рендеринге) я могу понять мобилка это или нет только через прокидование пропсов с серверных компонентов, в которых смотрю в headers.
Да, можно в теории передавать стили внутрь компонента, но мне не кажется это хорошей идеей.
Дополняю:
Вспомнил про еще один кейс - проверка авторизации и изменения view основываясь на типе пользователя (не зарегистрированный, зарегистрированный, премиум). Сейчас для этого есть два разных функционала - один для серверных компонентов, который смотрит в nextjs cookies. И второй - контекст для клиентских компонентов, который будет работать во время spa поведения. И опять же сталкиваемся с проблемой пререндеринга на стороне сервера. (Как объяснить клиентскому компоненту какой вариант использовать для пререндеринга, если не прокидывать пропсы на кучу уровней внутрь?) Отключить его полность (ssr: false) - не вариант, т.к. есть серьезные требования к seo и crawling от поисковиков.
Добрый день. Пользуюсь next.js не так давно. До этого писал только на angular. Согласен в целом со всем, фрэймворк выглядит интересным и многообещающим но многие вещи просто вводят в тупик. К примеру описанная вами проблема с пробрасыванием раутов или любых других данных в серверных компонентах. Я решил ее кастомной имплементацией кэша из next.js. В корне page.tsx добавляю данные в компонентах ниже - считываю. Возможно ваша библиотека делает тоже самое, не смотрел в деталях.
Но вопрос в другом - решили ли вы ( и решали ли) проблему с невозможностью переиспользования части функциональности между клиентскими и серверными компонентами? Пример банальный - узнать мобильное устройство используется или нет. На сервере можно использовать headers реквеста, в клиентском компоненте - media query. Но переиспользовать это решение нельзя, что ведет к другой проблеме - в клиентских компонентах нужно создавать дополнительный инпут пропс чтобы прокинуть начальное значение isMobile. Ведь иначе серверный рендеринг (изначальный) для клиентского компонента отрисует неправильный html, который потом будет прыгать когда подтянется значение из хука и media query. И это ведет к props drilling уже в клиентских компонентах.
Действительно работает!
Спасибо большое, видимо, отсутствие опыта с react сказывается. Думал про всякие динамически импорты и тому подобное, но просто сделать обертку не додумался. Единственное, что использовал контекст в root layout чтобы все используемые в проекте компоненты могли использовать, т.к. это глобальная фича.
Подсажите еще, пожалуйста, зачем разделять UserDeviceContext и SetUserDeviceContext ? Для того, чтобы уменшить вляние ререндеринга при измении любой из пропертей контекста и вместо этого пользоваться мемозацией примитивов?
А чем Вам не нравится режим серверного рендеринга?
Стили не всегда могут помочь. Самый базовй пример, у меня есть компонент кнопки. Пропсами в него передаются тип и размер. Т.е. для того, чтобы поменять размер кнопки с md на sm мне нужно изменить инпут параметр. Соответственно при перезагрузке страницы, когда серварная часть возвращает уже готовый html мне нужно знать мобильная версия или нет. И если компонент помечен как client, то mediaQuery отработает только в браузере, и кнопка поменяет размер.
Такая же проблема с изменением количества столбцов в masonry layout. У нас есть кнопка тригер, которая меняет кол-во столбцов, плюс разные возможные значения для мобильной и десктопных версий. Т.е. контролируется это через код, а не стили. Вот и получается, что в клинтском компоненте (при начальном рендеринге) я могу понять мобилка это или нет только через прокидование пропсов с серверных компонентов, в которых смотрю в headers.
Да, можно в теории передавать стили внутрь компонента, но мне не кажется это хорошей идеей.
Дополняю:
Вспомнил про еще один кейс - проверка авторизации и изменения view основываясь на типе пользователя (не зарегистрированный, зарегистрированный, премиум). Сейчас для этого есть два разных функционала - один для серверных компонентов, который смотрит в nextjs cookies. И второй - контекст для клиентских компонентов, который будет работать во время spa поведения. И опять же сталкиваемся с проблемой пререндеринга на стороне сервера. (Как объяснить клиентскому компоненту какой вариант использовать для пререндеринга, если не прокидывать пропсы на кучу уровней внутрь?) Отключить его полность (ssr: false) - не вариант, т.к. есть серьезные требования к seo и crawling от поисковиков.
Добрый день. Пользуюсь next.js не так давно. До этого писал только на angular. Согласен в целом со всем, фрэймворк выглядит интересным и многообещающим но многие вещи просто вводят в тупик. К примеру описанная вами проблема с пробрасыванием раутов или любых других данных в серверных компонентах. Я решил ее кастомной имплементацией кэша из next.js. В корне page.tsx добавляю данные в компонентах ниже - считываю. Возможно ваша библиотека делает тоже самое, не смотрел в деталях.
Но вопрос в другом - решили ли вы ( и решали ли) проблему с невозможностью переиспользования части функциональности между клиентскими и серверными компонентами? Пример банальный - узнать мобильное устройство используется или нет. На сервере можно использовать headers реквеста, в клиентском компоненте - media query. Но переиспользовать это решение нельзя, что ведет к другой проблеме - в клиентских компонентах нужно создавать дополнительный инпут пропс чтобы прокинуть начальное значение isMobile. Ведь иначе серверный рендеринг (изначальный) для клиентского компонента отрисует неправильный html, который потом будет прыгать когда подтянется значение из хука и media query. И это ведет к props drilling уже в клиентских компонентах.