В SolidJS, например, переосмыслили JSX. Там и для условного рендеринга, и для итерирования предлагаются специкомпоненты как раз для изкоробочной поддержки реактивности. То есть фактически не JSX неудобен сам по себе, а его реализация в React, хоть они его и придумали.
Но проблема в том, что мы пути описываем строкой, а как её типизировать? Только роутер в рантайме может это сделать.
Так в этой статье как раз приводится пример, как TypeScript может в compile time построить тип параметров пути, заданного статически. И в Tanstack Router аналогичный приём тоже используется.
В зависимости от того, с кем вы общаетесь Frontend, Backend разработчком или архитектором, представление о реактивном программировании может немного отличаться.
А ещё оно может различаться у разных людей, и, теоретически, об этом может зайти речь на собеседовании.
Вот как раз всегда и автоматически React не удовлетворяет.
Так если честно, то тогда только Svelte удовлетворяет этому правилу, потому что во всех остальных библиотеках реактивности придётся явно через них определять потоки и дёргать их геттеры/сеттеры/методы.
Иногда надо сделать явно setState
Это явно устаревшее и в функциональных компонентах недоступно.
На мой взгляд можно считать React реализующим принципы реактивного программирования большой натяжкой, с существенными ограничениями, и только в привязке к компонентам. Достаточно этого или нет - вопрос открытый. Как по мне - то нет.
Тем не менее при использовании современного React с функциональными компонентами приходится писать код в соответствии с принципами реактивного программирования, иначе ничего не заработает. Можно ли тогда говорить, что React требует использовать реактивное программирование?
Какая разница то, вызываешь ты форс апдейт или стейт меняешь - это в целом одно и то же.
Это разные вещи: в первом отрисовку активируешь вручную, а во втором она происходит автоматически, что как раз и требуется в реактивном программировании.
Попробуйте SolidJs и увидете что такое реактивность
Вы плохо прочитали мои комментарии, иначе увидели бы, что я и его упоминал. А ещё задолго до него был KnockoutJS.
Точечную отрисовку можно делать и без вдом, как например в preact
Так ведь preact (и vue) используют VDOM.
Вдом нужен был во времена экплорера, в котором дом работал медленно.
VDOM реакту и подобным библиотекам нужен ещё и для композиции компонентов.
Ререндер реакта это не совсем автоматическое обновление - можно было рендер вручную вызывать, после изменения стейта.
Это всё немного сложнее работает. Непосредственно рендер компонента порождает только vdom, а forceUpdate может инициировать реконсиляцию, но окончательно всё отрисуется только когда решит шедулер.
Ререндер наоборот указывет на отсутсвие реактивности
Если писать в таком стиле, что изменения данных не фиксируются явно в системе реактивности, и требуется постоянно делать forceUpdate, то да — это отсутствие реактивности. Но так писать очевидно неправильно. Тем более, что forceUpdate есть только у классовых компонентов.
Вообще это не так удивительно, учитывая java-бэкграунд Нетфликса, и то, что в те годы для JS практически никаких адекватных решений для реактивности не было.
А где, собственно, найти более-менее правдивый и полный список этих принципов? Разные сайты совершенно разные вещи пишут, а в документации Реакта принципы не перечислены.
Нет, почему же: реактивность интерфейса — это способность интерфейса автоматически обновляться при изменении данных, на которые он опирается. Что же касается точечного изменения DOM, то он точечно меняется и в React, но через промежуточную отрисовку Virtual DOM. Но к реактивности это всё равно относится сильно косвенно.
Да, потому что цикл обработки данных исторически был привязан к рендер-циклу. Поэтому сама реализация довольно убогая. С другой стороны, реактивность в React работает по pull-модели, когда данные втягиваются из потоков данных при необходимости, а не push-модели RxJS, когда они выталкиваются из потока. Но это не означает ущербность модели, просто в ней больше ленивости: просто нет смысла забирать и обрабатывать данные, если они не будут в конечном счёте отрендерены.
С этой позиции комментарий разработчиков React («Нам будет сложнее контролировать планирование, если мы позволим пользователям использовать подход «выталкивание при наличии данных», распространённый в функциональном реактивном программировании. Мы хотим, чтобы наш код был «связующим». В команде есть внутренняя шутка, что React должен был называться «Планировщик», потому что React не хочет быть полностью «реактивным».») следует понимать именно как следование pull-модели вычислений, а не когда события самостоятельно форсируют рендер.
Конечно, в более продвинутых реактивных реализациях, как у MobX, Vue, Solid, перевычисление зависимостей отвязано от рендер-цикла, и, соответственно, нет накладных расходов на непосредственно рендер виртуального DOM, но и они следуют pull-модели реактивности как более эффективной и даже более последовательной по духу функционального программирования.
Это одна и та же реактивность, только на неё смотрят с разных позиций. Должна существовать возможность выражать потоки данных и автоматически распространять изменения. В React поток данных может быть выражен хуками useState, useEffect, useMemo и так далее, а распространение изменений производится в рендер-циклах на основе списков зависимостей. Не самая красивая и удобная реализация, но как есть. Реактивное программирование в общем случае не требует, чтобы данные были явно завёрнуты в некоторые объекты потока и чтобы ими можно было оперировать явно, это всё может быть скрыто под капотом как в Svelte (или даже Excel).
Всё-таки в нём есть модель реактивности, хоть и реализованная довольно криво из-за легаси. Но считать реактивным программированием исключительно RxJS, в котором не меньше проблем, точно нельзя.
Почему же оно было абсолютно невероятным? Абсолютно невероятное — это событие с вероятностью 0. Здесь же вы оба поехали в Москву одной и той же осенью, причём намеревались сделать это заранее. Спектакль в театре, очевидно, заинтересовал вас обоих, что тоже не совсем совпадение, учитывая некоторую близость интересов. Ну и так далее.
И я ещё раз хочу сказать, что если бы произошло не это событие , а какое-то другое «невероятное» из всего множества «невероятных» событий , вы бы написали пост про него. Поскольку по определению, и — сигма-аддитивная мера, то либо множество состоит только из , и тогда его вероятность , либо если , то существуют какие-то другие «невероятные» события с ненулевой вероятностью.
Если рассматривать только «реальные факты», а не гипотетическое множество, как того требует теория вероятностей, то у таких событий вероятность равна 1, потому что они произошли.
Потому что если бы встретили не Петю, а Васю, не в театре, а в кафе, не в Москве, а в Петербурге, не том году, а в следующем, то вы бы рассказывали сейчас именно про это событие. И таких событий потенциально огромное множество, хоть и произойти они могут с крайне низкой вероятностью. Однако для поста на Хабре «Случилось совершенно невероятное событие» достаточно было бы, чтобы случилось любое из этих событий, а для этого нужно сложить все их вероятности.
Вы, разумеется, можете оценить вероятность случившегося события, но логическая ошибка в том, что вы не оцениваете суммарную вероятность всех событий, которые могли бы побудить вас написать данный пост.
В SolidJS, например, переосмыслили JSX. Там и для условного рендеринга, и для итерирования предлагаются специкомпоненты как раз для изкоробочной поддержки реактивности. То есть фактически не JSX неудобен сам по себе, а его реализация в React, хоть они его и придумали.
Банковский день закрывал?
Firefox 140
Chrome 138
Проще всего делать объект роута, например:
Привязывать компонент прямо к роуту нельзя, потому что возникнут циклические ссылки в компонентах, использующих эти роуты.
Главная задача: научить TypeScript правильно строить объект параметров пути из подобной строки, учитывая явно указанные типы.
Так в этой статье как раз приводится пример, как TypeScript может в compile time построить тип параметров пути, заданного статически. И в Tanstack Router аналогичный приём тоже используется.
А ещё оно может различаться у разных людей, и, теоретически, об этом может зайти речь на собеседовании.
Так если честно, то тогда только Svelte удовлетворяет этому правилу, потому что во всех остальных библиотеках реактивности придётся явно через них определять потоки и дёргать их геттеры/сеттеры/методы.
Это явно устаревшее и в функциональных компонентах недоступно.
Тем не менее при использовании современного React с функциональными компонентами приходится писать код в соответствии с принципами реактивного программирования, иначе ничего не заработает. Можно ли тогда говорить, что React требует использовать реактивное программирование?
Это разные вещи: в первом отрисовку активируешь вручную, а во втором она происходит автоматически, что как раз и требуется в реактивном программировании.
Вы плохо прочитали мои комментарии, иначе увидели бы, что я и его упоминал. А ещё задолго до него был KnockoutJS.
Так ведь preact (и vue) используют VDOM.
VDOM реакту и подобным библиотекам нужен ещё и для композиции компонентов.
Это всё немного сложнее работает. Непосредственно рендер компонента порождает только vdom, а forceUpdate может инициировать реконсиляцию, но окончательно всё отрисуется только когда решит шедулер.
Если писать в таком стиле, что изменения данных не фиксируются явно в системе реактивности, и требуется постоянно делать forceUpdate, то да — это отсутствие реактивности. Но так писать очевидно неправильно. Тем более, что forceUpdate есть только у классовых компонентов.
Вообще это не так удивительно, учитывая java-бэкграунд Нетфликса, и то, что в те годы для JS практически никаких адекватных решений для реактивности не было.
А где, собственно, найти более-менее правдивый и полный список этих принципов? Разные сайты совершенно разные вещи пишут, а в документации Реакта принципы не перечислены.
Могу ошибаться, но кажется, что виновато влияние Next.js.
Ну и в тему баг WONTFIX из Tanstack Router: https://github.com/TanStack/router/issues/2755
Нет, почему же: реактивность интерфейса — это способность интерфейса автоматически обновляться при изменении данных, на которые он опирается. Что же касается точечного изменения DOM, то он точечно меняется и в React, но через промежуточную отрисовку Virtual DOM. Но к реактивности это всё равно относится сильно косвенно.
Извините, но я всё же не понимаю, как это свидетельствует об отсутствии реактивности в React
Да, потому что цикл обработки данных исторически был привязан к рендер-циклу. Поэтому сама реализация довольно убогая. С другой стороны, реактивность в React работает по pull-модели, когда данные втягиваются из потоков данных при необходимости, а не push-модели RxJS, когда они выталкиваются из потока. Но это не означает ущербность модели, просто в ней больше ленивости: просто нет смысла забирать и обрабатывать данные, если они не будут в конечном счёте отрендерены.
С этой позиции комментарий разработчиков React («Нам будет сложнее контролировать планирование, если мы позволим пользователям использовать подход «выталкивание при наличии данных», распространённый в функциональном реактивном программировании. Мы хотим, чтобы наш код был «связующим». В команде есть внутренняя шутка, что React должен был называться «Планировщик», потому что React не хочет быть полностью «реактивным».») следует понимать именно как следование pull-модели вычислений, а не когда события самостоятельно форсируют рендер.
Конечно, в более продвинутых реактивных реализациях, как у MobX, Vue, Solid, перевычисление зависимостей отвязано от рендер-цикла, и, соответственно, нет накладных расходов на непосредственно рендер виртуального DOM, но и они следуют pull-модели реактивности как более эффективной и даже более последовательной по духу функционального программирования.
Это одна и та же реактивность, только на неё смотрят с разных позиций. Должна существовать возможность выражать потоки данных и автоматически распространять изменения. В React поток данных может быть выражен хуками useState, useEffect, useMemo и так далее, а распространение изменений производится в рендер-циклах на основе списков зависимостей. Не самая красивая и удобная реализация, но как есть. Реактивное программирование в общем случае не требует, чтобы данные были явно завёрнуты в некоторые объекты потока и чтобы ими можно было оперировать явно, это всё может быть скрыто под капотом как в Svelte (или даже Excel).
Всё-таки в нём есть модель реактивности, хоть и реализованная довольно криво из-за легаси. Но считать реактивным программированием исключительно RxJS, в котором не меньше проблем, точно нельзя.
Это пять!
Почему же оно было абсолютно невероятным? Абсолютно невероятное — это событие с вероятностью 0. Здесь же вы оба поехали в Москву одной и той же осенью, причём намеревались сделать это заранее. Спектакль в театре, очевидно, заинтересовал вас обоих, что тоже не совсем совпадение, учитывая некоторую близость интересов. Ну и так далее.
И я ещё раз хочу сказать, что если бы произошло не это событие
, а какое-то другое «невероятное» 
из всего множества «невероятных» событий 
, вы бы написали пост про него. Поскольку 
по определению, и 
— сигма-аддитивная мера, то либо множество 
состоит только из 
, и тогда его вероятность 
, либо если 
, то существуют какие-то другие «невероятные» события 
с ненулевой вероятностью.
Если рассматривать только «реальные факты», а не гипотетическое множество, как того требует теория вероятностей, то у таких событий вероятность равна 1, потому что они произошли.
Потому что если бы встретили не Петю, а Васю, не в театре, а в кафе, не в Москве, а в Петербурге, не том году, а в следующем, то вы бы рассказывали сейчас именно про это событие. И таких событий потенциально огромное множество, хоть и произойти они могут с крайне низкой вероятностью. Однако для поста на Хабре «Случилось совершенно невероятное событие» достаточно было бы, чтобы случилось любое из этих событий, а для этого нужно сложить все их вероятности.
Вы, разумеется, можете оценить вероятность случившегося события, но логическая ошибка в том, что вы не оцениваете суммарную вероятность всех событий, которые могли бы побудить вас написать данный пост.