Комментарии 18
Когда используешь React в связке с MobX, то нет разницы, React v16 или v17 или v18 или v19, в нём все необходимое и так есть уже давным давно. Всё на что способен реакт, это рендерить DOM с помощью удобств JSX'a. Для всего остального есть MobX и он справляется на 3 головы лучше ректа.
постойте ка, но ведь в статье нет ни слова про mobx ? Это такой способ привлечь внимание?
Это повод сказать, что Реакт очень медленно развивается, и этот релиз - в основном работа над ошибками, а не большой шаг вперед. Есть библиотеки как mobx, которые уже давно продвинули его на несколько шагов вперед, сделав удобный механизм работы со стейтом, и оставив Реакт только для рендера компонентов.
Я думаю, что именно на этом Реакт и должен концентрироваться, а не перерастать в большую неэффективную систему, пробуя на аудитории новые подходы в виде хуков (функции в функции с сайд-эффектами и невидимым кешем) со строгими правилами (или не очень строгими, а очень странными, как в случае с новым use) или серверные компоненты.
библиотеки как mobx, которые уже давно продвинули его на несколько шагов вперед
Жаль, авторы реакта держатся в стороне от этой темы, игнорируя подход на проксях. Со встроенным механизмом типа мобикса реакт был бы превосходным. Понятно, что использовать-то можно в связке, но увы, это не стало общепринятым стандартом..
Мутабельность можно сделать и с помощью других паттернов, прокси вовсе не обязательны. Главное - интерфейс, что при мутации значения происходит ререндер. Что не нужно делать ни useReducer, ни setValue. И жесткие ограничения на интеграцию с другими системами реактивности Реакт тоже не красят - намерение плотно привязать на его экосистему и его подходы как раз и мешают более эффективным решениям "стать общепринятым стандартом". Как бы сообщество ни хотело исправить это - получаем только новую пачку хуков, решающих проблемы, которых и не должно было бы быть.
Это повод сказать, что Реакт очень медленно развивается, и этот релиз - в основном работа над ошибками, а не большой шаг вперед. Есть библиотеки как mobx, которые уже давно продвинули его на несколько шагов вперед, сделав удобный механизм работы со стейтом, и оставив Реакт только для рендера компонентов.
Ну так Реакт - это библиотека для разработки интерфейсов, а не для управления состоянием. По-моему, очевидно, что полноценных средств для работы с состоянием там никогда не будет. И это правильно: хорошая библитоека сфокусирована на чём-то одном, а не пытается решить все проблемы на свете. Главное, чтобы Реакт был достаточно гибким для того, чтобы была возможность интеграции с библиотеками, решающими смежные задачи.
ну а react + mobx это vue или любой другой современный фреймворк на сигналах, которые еще в добавок перформят лучше виртуалдом
Наблюдаю за Реактом годов так 5. Скажити- "входить" в Реакт уже можно или уже поздно ?
Если установить в браузер расширение React Developer Tools, иконка которого становится цветной на страницах использующих React, то складывается ощущение что он используется практически везде в крупных проектах. А значит "войти" стоит определенно и все еще не поздно.
Но вот использовать его всегда и везде возможно не лучшая идея, есть более подходящие альтернативы для определенных задач.
Есть еще компании для которых реакт это нано технологии модные и бессмысленные )
Лучше в Ангуляр, тут и места всем хватит и теплее
Нельзя отказать команде React в грамотной стратегии, упорстве в намеченных целях и как следствие стремительном развитии экосистемы. Концентрация ресурсов в правильных руках, в данном случае, приносит ощутимую пользу сообществу. Поздравляю всех причастных!
Что по React Compiler?
Единственная функция, которую по-настоящему ждал от 19 реакта
Она вас не спасет: https://www.schiener.io/2024-07-07/react-closures-compiler
Это полный офтопик, но когда читаю такие статьи задаюсь вопросом на каком языке они написаны, почему в оригинале их читать на много проще чем в переводе. Видимо чаша терпения переполнилась и я решил порефлексировать на эту тему...
Например, фраза "В React 19 мы добавляем поддержку использования async-функций..." по-русски звучит проще "В React 19 добавлена поддержка async-функций...". В русском языке пассивный залог позволяет избавиться от лишней информации. В этой статье чуть ли не в каждом предложении "мы добавили", "мы улучшили" и т.д. И так понятно, что это сделали вы, зачем это постоянно повторять? С другой стороны, верно и обратное, когда переводишь с русского на английский, то нужно избавляться от пассивного залога, он усложняет понимание английского текста.
Или фраза "Для получения дополнительной информации смотрите документацию по use" проще звучит "Дополнительная информация доступна в документации по use".
"... чтобы упростить эту задачу, мы добавили новый хук useFormStatus" - проще звучит "... для упрощения этой задачи добавлен новый хук useFormStatus".
"В прошлых версиях использование пользовательских элементов в React было затруднено, поскольку React рассматривал нераспознанные пропсы как атрибуты, а не свойства" - проще "В прошлых версиях React было сложно применять пользовательские элементы, т.к. нераспознанные пропсы считались атрибутами". Тоже звучит коряво, но, на мой взгляд, мозг запинается немного меньше.
И практически весь текст такой. Причём не только здесь, но и в большинстве переводных статей на хабре. В любом случае, спасибо и автору за этот перевод, и другим авторам за другие переводы. Но хочется в целом подсветить эту проблему. Если её в принципе увидеть, то исправить не так сложно.
А потом люди начинают писать код и при его чтении у меня снова возникает ощущение, что они его получали от инопланетян из параллельной вселенной. На столько замысловато он иногда сформулирован. Вот, люди начитаются переводов, а потом и код пишут так же, например, строят лестницы в ад из Java-стримов:
var sourceModelVersion = modelComponentsProperties.getModelVersionRepository()
.findById(UUID.fromString(sourceObjectId))
.orElseGet(() -> modelComponentsProperties.getModelElementRepository()
.findById(UUID.fromString(sourceObjectId))
.filter(ModelEntity.class::isInstance)
.map(ModelEntity.class::cast)
.map(ModelEntity::getModelVersion)
.orElseGet(() -> modelComponentsProperties.getReviewNoteRepository()
.findById(UUID.fromString(sourceObjectId))
.map(r -> findModelVersion(r.getModelElement().getId()))
.orElseGet(() -> modelComponentsProperties.getFigureRepository()
.findById(UUID.fromString(sourceObjectId))
.map(f -> findModelVersion(f.getModelElement().getId()))
.orElse(null))));Если напрячь мозг, то конечно можно понять что имелось в виду. Но в ИТ и так достаточно вещей, над которыми можно напрягать мозг. Зачем создавать сложности искусственно? Текст должен читаться легко.
Короче пока меня не понесло дальше и я не начал разгонять, что язык определяет мышление, все проблемы нашей вселенной лежат в языковой плоскости, та же математика в значительной степени про язык, а не что-то ещё, и при этом она в основе всех наук... закончу сей пафосный трактат о судьбах человечества фразой из классиков: ты должен был бороться со злом, а не примкнуть к нему ИТшник, ты должен был упрощать всё, а не умножать сложность
Пха, большинство технологий стремится к усложнению, наверняка есть какой-то эмпирический закон на эту тему. Ведь только гениальное просто, а где гениев-то на всех набрать?
Я периодически с этим сталкиваюсь когда люди боятся трогать существующий код, пишут поверх всё больше и больше каких-то костылей. Даже строил графики по коммитам в Git, на которых видно, что подавляющее большинство людей только добавляют код и почти ничего не удаляют. А один-два человека пытаются бороться с этим хаосом и удаляют тысячи строк, при этом умудряются добавить новую функциональность или починить баги
Достаточно сложно вовлечь всех разработчиков в этот процесс уничтожения кода, но в принципе это возможно. На самом деле ИТ отличается от науки или искусства тем, что все задачи здесь вполне формализуемые, декомопзируемые. И если в какой-то момент разработка просто останавливается из-за сложности, то это вполне решаемо
Вот, люди начитаются переводов, а потом и код пишут так же, например, строят лестницы в ад из Java-стримов
Ну, это обычная некомпетентность. Люди пишут код в функциональном стиле там, где лучше подойдёт императивный.
Вышел React v19