Comments 41
Что произойдет если одновременно, из нескольких мест одного компонента произойдет вызов state = x (текущий стейт y)? Как компоненту понять что состояние поменялось?
з.ы. <skz>Вот же этот Ден Абрамов, стервец, дурачит газилионы и газилиарды разработчиков!</skz>
Как я понял там для этого есть component.update аналог реактовского forceUpdate
<skz>Вот же этот Ден Абрамов, стервец, дурачит газилионы и газилиарды разработчиков!</skz>
Пишу на реакте с 2015-го. И что-то не ощущаю профита в разработке от стольких лет его эволюции. Скорее наоборот, разработка на нем стала сложнее и медленнее(
Каждый стейт обычно относится к своему элементу, поэтому лучше и обновлять их по отдельности.
Но можно сделать и так: https://codesandbox.io/s/fusor-analog-clock-jsx-hqs5x9?file=/src/index.tsx
А можно не заморачиваться и инициировать проверку обновления всего приложения с корня, сделав throttling (как примерно у Реакт).
Вся прелесть в том, что теперь есть контроль над процессом обновления.
Вся прелесть в том, что теперь есть контроль над процессом обновления.
Скорее головная боль из-за необходимости думать, что надо обновить, а что не надо и как обновить родителя так, чтобы не началось обновление всех его детей.
В реакте, внезапно, тоже надо об это думать. А если не думать - на каждый чих у вас будет ререндер, вплоть до всего приложения.
То есть главная проблема Реакта так не решена, продолжаем колоться и есть кактус, но уже другого цвета.
Я бы сказал проблема молодых "я же программист" не решена. Пишем на реакте сложные приложения и при грамотной декомпозиции приложения никогда не возникало проблем с обновлением всего дерева разом. Конечно, если писать компоненты на 500 строк кода, то потом легко говорить, что реакт фуфло и к него проблемы с обновлением
Мне нравится, когда стейт может реактивно связываться с конкретными узлами DOM.
И прикалывает, что JSX изобрели для того, чтобы каждый раз генерить новую строку шаблона. И потом все удивляются, а почему это движок реакта что-то просмотрел (недовычислил) и рендерит DOM заново. Так не юзайте JSX как минимум для ререндера.
В реакте тоже самое
Самописное всегда будет лучше. Чем дольше эволюционирует фреймворк или библиотека - тем больше в нем накапливается всяких нелогичных элементов. Я уже не говорю, а ключевом недостатке изначально (из коробки) возникающему у любого внешнего продукта.
НО у самописного есть один недостаток для использования его во внешних проектах. Bus factor == 1.
Маленький пример маленького компонента - это конечно весело показывать в выгодном свете. Но если хочется именно попытаться собрать комьюнити и попробовать занять хоть немного места в нише фронта, то видится мне, что для популяризации очередного "убийцы реакта", надо не показывать очередной каунтер с кнопкой, а брать большой серьезный проект на том же гитхабе и переписывать его на своего "убийцу реакта".
И писать уже большую серию статей с конкретными примерами, в чем именно стало лучше и проще и выводами, по типу:
кодовая база сократилась на N%
размер бандла сократился на M%
скорость сборки ускорилась на L%
производительность на клиенте улучшилась на K%
время разработки теоретически могло сократиться на J человекочасов
Без серьезного подхода и серьезных выводов - на либе и через год максимум кто-то набросает очередной каталог фильмов и очередные туду-листы.
Все когда-то начиналось с маленького...
Я один человек с основной работои и семьей. То что вы описали под силу множеству людей. Поэтому-то я и пытаюсь продвинуть этот проект в массы. Так что если поможете, я буду очень вам благодарен.
Кстати, в репе на гитхаб есть еще несколько ссылок на примеры побольше, и на два полноценных приложения. И документации уже накопилось порядочно.
Я бы не назвал полноценными приложениями - мелкие примеры на десяток файлов.
Еще раз - основная проблема продвижения очередного "убийцы реакта" в том, что на самом реакте люди, от которых зависит выбор стека (хотя бы для внутренних проектов компаний, на внешние никто в здравом уме не потянет кота в мешке), понаписали многие сотни тысяч и миллионы строк кода, понимают минусы-плюсы различных решений на реакте, знакомы с десятками и сотнями библиотек, знают, что при росте проекта всегда смогут найти разработчиков. Им от этих мелких примеров - ни холодно ни жарко.
Нужен действительно большой проект и в первую очередь ориентированный на всякие админки (только на подобных проектах еще возможно затянуть в прод не самое популярное решение "для опыта", если мы говорим о чем-то больше туду-листа на гитхабе). Со всякими графиками, формами, таблицами, пагинациями, правами и тд.
Все эти примеры в репе - конечно окей, но в реальности это было просто потерей времени, которое ничего не даст. Я серьезно, ищите большую админку и переписывайте на свою либу сопровождая серией статей с процессом переписывания и выводами - выводами в чем плюс выбрать именно данную либу, на фоне уже имеющихся и привычных многим решений.
Согласен, чтобы действительно претендовать на то, что Fusor лучше чем React, нужно сделать пару тройку проектов серьезных, а затем уже сравнивать, но автору хочется тоже сказать спасибо, не зря же старался писать другую либу:)
Хорошее замечание. Если тудушка или каунтер, как примеры, не подходят (хотя много кто верит, что именно тудушка показывает всю мощь той или иной библиотеки), то что тогда показывать?
Калькулятор? Я на полном серьезе. Там куча кнопок, можно рективность влепить, показать как библиотека работает с темплейтами.
Realworld?
Как верно замечено, нужен минимум Realworld, а еще лучше какая-нибудь большая админка на реакте, взять тот же react-admin. Чем больше в проекте разнообразных фич будет покрыто - тем больше кейсов выплывет, когда либу придется переписывать и патчить, порой отказываясь от неудачных решений и концепций вообще.
Сейчас, на основе этой статьи как-бы особой ценности от либы не видно вообще, кроме того, что будет чуть меньше строк кода из-за отсутствия useState да useCallback, но получив за это фактическое отсутствие реактивности. Это очень странный кейс для продвижения.
Ну право, сейчас не времена jQuery, чтобы можно было выехать только на наличии jsx синтаксиса. Нужны реальные причины, для чего разрабу брать в проект неоттестированную либу с кучей неизвестных подводных камней, о которой только известно то, что на ней покороче туду-листы с каунтерами получаются.
Вообще понять о библиотеке лучше всего можно как раз по таким простым примерам. И они все покрыты в документации. Если вам не хватает какого-то конкретного кейса, то милости прошу, приведите пример.
А то что вы хотите увидеть тяжелое приложение с кучей зависимостей, это ничем вам не поможет, только субъективно оценить производительность. Поэтому у меня в планах сделать сравнительный бенчмарк, для объективной оценки производительности.
Похоже мы немного о разных задачах для примеров говорим.
Маленьким простым примерам - место в документации, просто показать использование очередной фичи коротким куском кода.
Большое сложное приложение - позволяет показать в реальной жизни жизнеспособность либы, применяемость различных фич либы, различные трейдофы (а они есть всегда) и как их оптимальнее обыгрывать и тд. Да еще и в процессе переписывания такого приложения повсплывает всякое, что заставит выпустить еще десяток версий.
Предлагается, как бы, либа, вокруг которой будет строиться всё приложение и мало кому хотелось бы самому собирать все возможные грабли, а в итоге понять, что тоже самое на реакте было бы лучше, удобнее, быстрее, производительнее, понятнее, протестированнее, менее глючное, да еще и разрабов не надо переучивать.
То есть логику когда именно делать ре-рендер переложили на пользователя библиотеки?
Чем вам VueJs не угодил?
В Реакте вы тоже делаете ререндер вручную, вызовом setState(x). Видите насколько это не явно?
Во Fuser, во первых все явно state = x; update();, а во вторых более просто в имплементации.
Во Fuser стейт это просто переменная Javascript let x = 0, во Vue это срытый и более сложный механизм на подобие хуков.
«На лицо» некое непонимание: вы как-то легко расстались с реактивностью (в данном случае со стейт-реактивностью) и называете это улучшением.
Товарищи Чуваки!
Оцените только что придумаюнную мною шутку: программирую на C+++
Вариант№ 2: програмирую на Jaba
На самом деле существует бесконечное множество самых различных вариантов! Или нет?
Я - Fullstack, но почти 7 последних лет работал чисто с Backand'ом. Сейчас возвращаюсь во Frontend. Немного шокирован как всё поменялось за эти годы. Месяц работаю с React'ом и вот у меня ровно те же мысли что и у автора! Хочу более простого/примитивного взаимодействия со state'ом, полный контроль над запуском рендринга компанента. И в целом, хочется большей прозрачности в том что происходит. Буду внимательно следить за развитием вашего проекта! Автору респект и удачи!
Хочу более простого/примитивного взаимодействия со state'ом
Используйте MobX и будет вам счастье, забудете о неудобствах как о страшном сне.
Вот - https://codesandbox.io/s/adoring-banach-k8m9ss?file=/src/App.tsx
Fusor vs React