Https://Reactjs.Org/Blog/2020/12/21/Data-Fetching-With-React-Server-Components.Html Кто нибудь понял как это будет работать и зачем вообще

это нужно?

будет работать нормально, нужно что бы стало лучше

Там внизу описание чем они являются и чем не являются

А, не здесь

Работать будет на ноде. Нужно для возврата в волшебные времена php

Вот здесь https://github.com/reactjs/rfcs/blob/2b3ab544f46f74b9035d7768c143dc2efbacedb6/text/0000-server-components.md

думаешь только нода засупортится? я просто не искал инфу по суппорту 🙂( официально, через пакеты). Костыли всегда можно прикрутить

Ну или на дено. Вряд ли кто-то научит пыху или гошку исполнять js :)

я про C# и им подобным

Серверные компоненты — это js. Его исполнить нужно на сервере

graalvm

еще прикрути сюда питона..

тоже верно, согласен 🙂

он и так там

но если без шуток, то для того чтоб срезать размер бандла на библиотеки, которые нужны только для статики

Где там?🤔

в graal

🥲

вот кстати хз. Возьем их пример с date-fns. Я чет не примоню ниодного проекта что я делал, где манипуляции с данными нужны были только для “статики”. IMHO ооочень спефифичный кейс когда это нужно.

вот да. те же сомнения у меня

нужно не забывать, что они решают сначала проблемы фейсбука, а потом выкатывают решение для всех

ну на проблемы фейсбука мне в данном случае все равно, я рассуждаю с точки зрения разработки вне фейсбука

preact

Такое

Что это значит?)

да preact тут не причем, я ведь старасюь понять есть ли реальная польза от server components.

От приложения и его инфраструктуры сильно зависит

Вцелом факт "мы хотим внести поддержку серверных компонентов в ядро ui библиотеки" уже наталкивает на то что мы уже свернули куда то не туда)

ну вот конертно их пример “смотрите как мы избавились от date-fns в клиентком бандле”, мне кажется это очень надуманый кейс

хотя глняул демку. Если четко разграничмивать какая часть компонентов подвержена динамике а какая нет, то в целом можно добится чтобы лишнее не лезло в бандл

у меня spa, многоязычный интерфейс, даты тоже должны форматироваться на клиенте налету

ну короче тут идея что если в какой момент даты не подвержены динамике, то можно и не тащить форматер. Хотя один фиг слабое утешение когда тебе можно не тащить dayjs но нужно тащить react-dom 😂

Хотя если копать глубже, то бывают реально страницы с малым кол-вом динамики, и которые хорошо бы отрисовывать на сервере максимально быстро, выбивая 98-100 баллов в лайтхаусе, и вот тут бандл для этой страницы реально может сильно сокртится при использовании server component. В целом я вспомнил пару случаев из прошлых проектов где в теории это могло бы зайти.

Тогда возникает другой вопрос, зачем на таких проект реакт?

дак я про отдельные страницы на проекте где для остальных частей react оправдан. И на этих страницах есть в том числе и общие компоненты которые хочется реюзать.

🤔

ну это такой нишевый кейс. я думаю, они целятся на что-то большее

да чет смотрю я на все свои бывшие проекты и в целом то это не пригодилось бы только на одном/двух.

ну так это по паре страниц же. все равно главная "аппа" всегда динамическая

мне кажется это применимо для всех публичных страниц. То есть все “лендинги”, все вариации катологов, страниц поисков

тебе, конечно, виднее чем разработчикам реакта

вот это аргумент так аргумент

ну хз, у меня есть несколько кейсов, где для одного-единственного элемента UI тянется здоровенная либа. MDX отрендерить, динамически отрендерить иконки из двухмегабайтного списка

да я уже написал ниже, что есть класс страниц где это может пригодится

ну в теории прикольно

как же много он болтает

rfc почитай

совсем новый принцип. Дэн радует. Мне понравилось

ужасно в первом приближении же

чем ужасно?

Да почему ужасно-то?)