Comments 35
Борьба с симптомами, а не болезнью.
Просто в Реакте эволюционно получился аналог подхода с использованием сигналов как в Mobx, Vue или SolidJS, только вывернутый наизнанку. То есть в упомянутых фреймворках определение зависимостей, мемоизация и цикл пересчёта данных находятся под капотом, а в React hooks их пишет сам программист. Да и в целях сохранения обратной совместимости получилось всё равно не так эффективно, как могло быть.
Новый день - новый пост про useCallback и useMemo) вы правда только спустя 6 лет работы наконец-то разобрались, зачем они нужны?
Кстати, у меня есть Telegram-канал
То есть чтобы проапдейтить какой-то сильно вложенный плейсхолдер, ты ререндеришь всё приложение, а потом пытаешься пофиксить посадку перформанса мемоизацией логики в компонентах которые посередине вложены?
Вот после таких решений и рождаются анекдоты про программистов и их костыли.
Ваша статья, яркий пример того, с чем можно столкнуться большое приложение от использования просто React из коробки. Ваше решение похоже на временную меру и суть проблемы не решает. А проблема скорее всего в том что слишком много DOM обновляется на каждый чих.
В вашей ситуации так и просится глобальный стор, который будет хранить все переменные, а эти переменные будут читаться там где надо через специальные компоненты с использованием useSelector. Когда надо обработать событие будет использоваться компонент с вызовом useDispatch, Тем самым получается то, о чем говорят выше - аля использование сигналов только на React.
Выше правильно сказали, в React нет сигналов из коробки. Для этого нужно отдельная зависимость. Redux частично может взять на себя роль сигналов.
У нас есть Redux, глобальные переменные и так там хранятся.
Но проблема в том, что плейсхолдеры определяются пользователем в текстовых полях. Следовательно, заранее неизвестно в каком именно компоненте какой плейсхолдер будет нужен и какой (или какие) selector'ы будут нужны в каждом из 50 возможных типов блоков.
Обратите внимание на сигналы https://preactjs.com/guide/v10/signals/. Ваша проблема звучит так, будто сигналы прекрасно могут её решить
Судя по вашему комментарию, пользовательские плейсхолдеры хранятся в самом компоненте, а не в глобальном стопе. Отсюда и все проблемы. Если перенести пользовательские плейсхолдеры в глобальный стор и читать их только там где нужно, точечно выполняя перерендер то это решит проблему.
Как вариант в сторе завести 50 коллекций под каждый тип блока и по уникальному индексу связывать переменные блока (плейсхолдеры) с компонентом.
Когда компонент монтируется, он может вызвать useId() хук который вернёт уникальный ключ текущего компонента, или использовать ключ из базы данных для блока, вы ведь как то их сохраняете.
Спасибо за статью, было интересно почитать про внутреннее устройство конструктора кликеров.
Волосы:
Обновлялись до React 19? Вроде как там обещают оптимизацию useMemo/useCallback
Использовать в каждом компоненте useCallback/ useMemo - означает быть подверженным человеческому фактору - лень, забыл, сроки горят. Искали ли вы системное решение данной библиотеки в виде другой библиотеки/своего хука. Мб замена redux на Zustand/Mobx сможет излечить одну из этих родовых травм?
Ещё возможно вариант, что вам нужно дополнительно оптимизировать Инпуты - чтобы они не делали лишние действия
Нет, мы ещё на 18-й (но нам и не нужна доп. оптимизация хуков, нам и текущей реализации хватает).
"Означает быть подверженным человеческому фактору" - с одной стороны, да. С другой стороны, специфика проекта и проверяем такое на код ревью.
Другие стейт библиотеки ситуацию не изменят, тут проблема в самой необходимости динамически обновлять заранее неизвестные поля глобально.А мы так и сделали. У нас кнопка и есть инпут, который вызывает события. Мы её задебоунсили
Отойдя от темы реакта. Меня одного смущает, что в качестве примера применения этих функций выбран очередной криптоскам в стиле хомяка? 🤔
Я занимаюсь фронтенд разработкой на React последние 6 лет (в роли full-stack разработчика). Я знал и слышал, что существуют хуки useCallback и useMemo, которые нужны для оптимизации рендеринга. При этом про их использование я слышал только в теории или на собеседованиях.
Это шутка? Статья была заготовлена для 1 апреля? Или под "последние" вы имеете ввиду что больше не будете разрабатывать на реакте?
Мемоизация уже заметно помогает при рендере больших списков, где нужно прокинуть хотя бы один параметр вниз, в каждый дочерний компонент. Т.е. вы за 6 лет не делали интерактивных приложений, а только условные лендинги?
Я вам могу даже один пример зачем нужна мемоизация показать, но там видно, что новичок писал статью, а не человек с 6 годами опыта. https://habr.com/ru/articles/873044/comments/#comment_27773258
Но если рассматривать вашу проблему, а не отдельно мемоизацию, то вам сторы не помогут. У вас в принципе проблема с проектировкой системы и использованием технологий. Можете просто почитать статьи аля "React best practice", "React in action".
У вас в статье даже нет информации о профилировании...
Поэтому оптимизировали всё, что можно было оптимизировать
"На глаз" это не решение, "на глаз" это костыль.
У вас проблемы с теорией, пробежаться глазами, а тем более бежать от проблемы (ставя минусы комментам и не замечать) не даст вам никакого профита.
Забавно читать комментарии тех, кто критикует архитектуру автора но фактически не предлагает ничего конкретного )
Кто в комментах критикует архитектуру?
Её невозможно критиковать, потому что автор не предоставил информации о ней.
Максимум что есть, это конкретное решение про мемоизацию.
Собственно это решение и критикуется, а точнее подход автора к решению проблемы.
При этом заявления автора, что он только через 6 лет понял на практике эффективность мемоизации, вызывает минимум улыбку.
И что ему предложить? Люди в комментах попытались догадаться что и как у автора сделано, попытались предложить решения на основе своих догадок.
Или вы предлагаете собрать список статей по реакту и скинуть ему ссылки в коммент?
Если такие проблемы с мемоизацией, то явно есть проблемы в принципе с теорией.
Ну так займитесь тогда этим.
По статье можно сделать вывод о том, что у автора проблема с использованием технологий, а от сюда уже вывод о том, что скорее всего и проблема с проектировкой, т.к. шанс удачной проектировки системы без теории 50% (либо нормально либо нет).
ИМХО, тут не с реакта надо начинать... А с основ композиции/декомпозиции и переиспользования компонентов/кода...
Особенно забавно наблюдать, как 8-летние реакт-архитекторы спорят с 7-летними реакт-CTO, как правильно строить архитектуру на Реакте, что в принципе не возможно (я пробовал). И никого даже не смутило 75к строк кода для такого не хитрого приложения. Для сравнения во всём $mol портале вместе со всеми зависимостями кода в 2 раза меньше.
Тут нет спора про архитектуру. Чтобы про неё спорить нужно чтобы были какие-то тезисы про архитектуру. А пока что тут только догадки про архитектуру.
Я вообще не понимаю как может ещё существовать React, когда есть $mol! Ведь если это такой крутой фреймворк, то он уже должен был давно вытеснить React с рынка. У него то точно правильная архитектура заложена, не то что у реакта, на котором строить архитектуру не возможно.
В параллельной вселенной, где люди действуют рационально и не думают чужим задним умом, Реакт даже не появился.
В параллельной вселеной много чего сделано по другому.
Но это не означает, что всё что хорошо "там", будет так же хорошо и для "здесь".
Вы можете сколь угодно много заниматься научной работой, но только часть из наработок попадёт на рынок и будет жизнеспособными.
На исследования выделяется отдельный фонд. Если бизнес будет все деньги тратить только на исследования, то он не будет зарабатывать. Поэтому в бизнесе много типовых задач, для решения которых ты будешь использовать одни и те же инструменты, т.к. такое сочетание позволит удешевить и ускорить разработку, а так же принесет прибыль.
Это вы сами придумали или цитируете манифест говнокодера?
Как много примеров компаний вы знаете которые закрылись из-за плохого фронта?
Если следовать вашей статье, то нужно ставить условия бизнесу, а не искать компромиссы.
Но если вы так будете делать, то бизнес найдет более подходящего разработчика, который за неделю склепает фиг пойми что, фиг пойми как, главное что будет работать и денег меньше потратит. И продукт запустят через неделю, а не через месяц.
Если бы бизнес думал о том, как сделать лучше в долгосрочной перспективе, то в каждой стране были бы заводы и везде был бы замкнутый цикл производства. Но почему-то бизнес импортирует товар за три копейки и продает в сто раз дороже, нежели производит за 30 копеек и продаёт в 10 раз дороже.
Там, где есть риски, есть и потребность выбирать менее популярные, но более подходящие и менее рискованные (в данном случае под менее рискованным подразумевается больший контроль над технологией и независимость) подходы. Но это тот случай, когда мы говорим про возможные потери бизнеса.
Чем больше разработчиков знающих определенную технологию, тем меньше рисков у бизнеса.
И поэтому написать костыль для известной штуки дешевле и меньше рисков, чем брать малопопулярную технологию.
Вы почему-то используете тезис, что "Давайте сделаем уникальное решение, которое на 100% будет подходить для нас", но при этом забываете, что такое решение придется как поддерживать, так и обучать новые кадры для работы с данным решением. Хотя использовать известную технологию и подогнать её под себя тоже не является бескомпромиссным решением, но всё же в обоих случаях есть компромиссы.
Т.е. если мы говорим про известную технологию, то меньше рисков, что столкнемся со специфичными багами, что в будущем нужно будет долго разбираться в легаси, что новые сотрудники будут долго вкатываться в процесс. Но получаем проблему с зависимостью от мейнтейнеров.
Это же прям в вашей статье написано, что вы выбрали непопулярное решение (Dart) для веба и столкнулись с проблемами в процессе разработки, что в итоге стоило денег компании.
Возможно проблема в том, что вы понимаете под популярностью и известностью - хайп, а не зрелость и распространенность. Поэтому вы неверно толкуете высказывания других пользователей.
Краткое резюме вашего опуса: гляжу в книгу - вижу фигу.
У вас явно проблемы с коммуникацией, поэтому не понимаете почему везде есть компромиссы, в т.ч. в разработке. Да, в программировании компромиссов почти нет, но мы говорим про разработку, а не про научный подход.
Мне вас в некотором смысле жаль, т.к. явно знания есть, но вы не можете их реализовать из-за зашоренности.
а вы всё никак не смиритесь с тем, что на ваш $mol всем насрать) причём дело ведь не в том, что за реактом и прочими стоят корпорации. за solid.js например мало кто стоит, но про фреймворк знают, им интересуются. ему даже приписывают авторство сигналов. думаю, в данном случае дело за личностью, которая стоит за $mol, не находите?) и ваши комменты здесь это подтверждают. как только столкнулись с аргументированными, развёрнутыми мнениями на тему, которую сами и подняли - сразу стали отвечать однострочным бредом. не думаю, что у человека с подобным отношением к критике(и к чужим успехам, дада) может получиться что-то стоящее
И не пересоздаётся функция в случае, если не изменилось состояние, важное для её работы.
Важно уточнить, что компонент, в который будет передаваться такая функция, должен быть обёрнут в memo.
Объясните пожалуйста что значит
МетодhandleClickпереопределяется на каждое изменение глобального состояния.
Метод
handleClickпереопределяется на каждое изменение глобального состояния.
Что это значит? Там же в любом случае каждый раз функция пересоздаются для того чтобы прокинуться в useCallback. Имеется ввиду handleClick будет иметь ту же ссылку при каждом вызове при использовании с помощью useCallback и тогда компонента не будет перерендериваться каждый раз?
Кейс применения useMemo и useCallback в React для оптимизации рендеринга при изменении глобального состояния