Я, признаюсь, посмотрел только код автокомплита, и для себя все понял. До продакшн решения тут как пешком до луны. По большому счету, вы ничего то и не сделали.
Компонент кнопки (button) у меня уже есть в html, нет, реально, ни одной причины делать кнопку в виде веб-компонента. Большая часть остальных, типа Chip, Badge и т.д — делается несколькими строчками цсс. Ну и т.д.
Что реально нужно — автокомплит — маст хэв, только ваш готов процентов на 5, не более. Редкие и не везде нужные, но все же такие вещи, которые на цсс не сделать, например dual-range. То есть, не надо паковать то, что уже есть в хтмл в веб компоненты, надо предлагать то, чего нет.
И хотя я оцениваю решение на условные 5 из 10, в целом — плюсанул, потому что сам веб компоненты люблю, и считаю их недооцененными.
Попробуйте сделать какой-то один, но с полной поддержкой всего. Например, автокомплит должен уметь в множественных выбор, в поиск по опциям, в кастомизацию выбранных опций и самих опций + вести себя для браузера так же как инпут, то есть уметь в валидацию, в :valid, :invalid, :required :empty и тд и тп.
Да, правильно. Но не совсем по той причине, что описаны в статье. Автор пишет:
основанное на наших собственных домыслах о работе JS
Но в итоге статья основывается на тех же домыслах. Давайте на примере вашего хука, посмотрим где реально проблема. Возьмем хук (я написал псевдо хук, но оригинал в реакте именно так работает):
function useState() {
// ...
return [get, set];
}
И то как он используется:
function Component() {
const [state, setState] = useState()
}
Прочитав статью можно сделать вывод, что проблема здесь в переборе итератора, или как автор пишет:
for (let index=0; index<arr.length; index++) {
if(index===3) {
value = arr[index];
}
}
Что в общих чертах напоминает работу механизма Array Assignment Pattern (перебор итератора).
Но это заблуждение и подмена смысла, проблема не в самом переборе итератора, а в том, что это каждый раз новый итератор. Чтобы это понять, нужно еще раз посмотреть, что именно происходит когда мы используем useState (в обратном порядке):
const [state, setState] = useState();
Аллоцирем память под новый массив, который каждый раз попадает в случайную область памяти.
Вызываем функцию useState, которая возвращая нам массив – делает тоже самое – аллоцирует память под новый массив на каждом вызове, а массив попадает в случайную область памяти:
return [get, set] // !!!
Из этого следует, что JIT вообще никак не может заинлайнить или оптимизировать этот код, он непредсказуем и память фрагментирована. В этом суть проблемы, а не в самом переборе итератора.
А бизнес-логику приложения перенести из каждого события в функцию переходов (она же редуктор).
А можно не выдумывать сложности там где их нет, и не пытаться оправдать существование редакса, с его уродским синтаксисом, тем, что якобы мы, решая некую там задачу – к нему же и придем.
const handler = {
currentState: undefined;
handleEvent(event) {
this.currentState = event.type;
switch (event.type) {
case "play":
// ...
break;
case "pause":
// ...
break;
case "ended":
// ...
break;
case "timeupdate":
// ...
break;
case default;
// ...
}
}
}
// audio = HTMLAudioElement
audio.addEventListener(handler);
// later
audio.removeEventListener(handler);
Какой практический смысл в том, что вы преобразовали play, pause, ended и timeupdate в PLAYING, STOPPED, PAUSED и ENDED?
Сделаем независимую от бизнес-логики библиотеку,
Что вам это дало?
чтобы и в реакте работало,
А если Vue? Angular? Solid?
чтобы и обновление частей состояния не вызывало перерисовки!!
Значит ли это, что при обновлении части состояния, например с PLAYING на PAUSED, пользователь это не увидет?
Чтобы были плагины в браузере для истории переходов!
Чтобы что? Для чего? Да, мы знаем, что редакс подает как мегафишку то, что вообще говоря почти никогда не требуется, а если требуется, то очень легко реализуется и без него?
Поехал с сыном в Южную Корею через Пекин, прошлой весной. Тогда можно было находиться три дня без визы. Поэтому в Пекине тусили два дня, было очень интересно!
Вызвал такси, чтобы куда-то поехать, сели сзади и пристегнулись, а водитель был не пристегнут! Мы ехали по аналогу нашего третьего кольца в Москве, и считали с сыном сколько в среднем камер на каждом столбе. У нас вышло штук 8! Когда съезжали с кольца, на каком-то перекрестке были местные полицейские, и только тогда водитель пристегнулся! А удивился и спросил — а как же камеры, на что он мне ответил типа — ай ерунда, не работают.
Вторая вещь которая удивила, это решетки на всех окнах. Везде!
это спровоцировало начинающих разработчиков плодить антипаттерны:По типу написания
this.users.push({})
this.render()
А когда вдруг this.users.push(user) стал антипаттерном? А, точно, когда те же ребята изобрели редакс, и продали всем идею, что this.users.push({}) неправильно, а правильно что-то вроде:
useCallback, useMemo нужно рассматривать в первую очередь для работы в связке с HOC memo, что бы гибко обходить самую распространенную причину лагов - избыточный перерендер, а не для того что бы экономить память
То есть, нам нужно использовать костыли useCallback и useMemo, чтобы работал еще один костыль – HOC memo, чтобы обходить ре-ренддеры возникающие из-за неравенства ссылок текущих и предыдущих пропсов возникающих вообще из-за использования хуков? Третий раз спасибо.
_$<п04ему?
Токсик! )
Только условия валидации это очень незначительно, и меняется редко, а «добавить фильтр» — наоборот.
Вам не кажется. Подано как очередная серебряная пуля, а по сути — пшик. Собственно поэтому мой комментарий выше остался без ответа.
Далеко вам до джаваскрипта))
У нас await работает с любым thenable объектом, а это любой объект, у которого есть метод then.
P.s. заголовок у вас кликбейтный, конечно, вы же не await реализовали, а awaitable result)
700 от куда-то взялся, а откуда, и в чем он? 700 грамм? 700 тон?
Что делается исключительно через прибитый гвоздями к реакту способ управления состояния. Хуки, то есть.
О боже, мы обречены…
Где-то я это уже читал…
А, точно: https://habr.com/ru/articles/968384/comments/#comment_29145688
Если бы не интернет эксплорер, ой, извините — сафари))
Ладно, сами напросились…))
Я, признаюсь, посмотрел только код автокомплита, и для себя все понял. До продакшн решения тут как пешком до луны. По большому счету, вы ничего то и не сделали.
Компонент кнопки (button) у меня уже есть в html, нет, реально, ни одной причины делать кнопку в виде веб-компонента. Большая часть остальных, типа Chip, Badge и т.д — делается несколькими строчками цсс. Ну и т.д.
Что реально нужно — автокомплит — маст хэв, только ваш готов процентов на 5, не более. Редкие и не везде нужные, но все же такие вещи, которые на цсс не сделать, например dual-range. То есть, не надо паковать то, что уже есть в хтмл в веб компоненты, надо предлагать то, чего нет.
И хотя я оцениваю решение на условные 5 из 10, в целом — плюсанул, потому что сам веб компоненты люблю, и считаю их недооцененными.
Попробуйте сделать какой-то один, но с полной поддержкой всего. Например, автокомплит должен уметь в множественных выбор, в поиск по опциям, в кастомизацию выбранных опций и самих опций + вести себя для браузера так же как инпут, то есть уметь в валидацию, в :valid, :invalid, :required :empty и тд и тп.
Направление вы выбрали правильное, на мой взгляд.
Ну просто авторы реакта не стали его преждевременно оптимизировать, понятно же)
Вообще не понимаю, каким образом у них такой низкосортный контент набирает сразу после публикации по 20 плюсов, и главное, зачем им это?
Даже читать не стал, просто плюсик поставил.
Каждый раз когда приходится открывать икскод, у меня случается нервный тик!
Да, правильно. Но не совсем по той причине, что описаны в статье. Автор пишет:
Но в итоге статья основывается на тех же домыслах. Давайте на примере вашего хука, посмотрим где реально проблема. Возьмем хук (я написал псевдо хук, но оригинал в реакте именно так работает):
И то как он используется:
Прочитав статью можно сделать вывод, что проблема здесь в переборе итератора, или как автор пишет:
Но это заблуждение и подмена смысла, проблема не в самом переборе итератора, а в том, что это каждый раз новый итератор. Чтобы это понять, нужно еще раз посмотреть, что именно происходит когда мы используем
useState(в обратном порядке):Аллоцирем память под новый массив, который каждый раз попадает в случайную область памяти.
Вызываем функцию
useState, которая возвращая нам массив – делает тоже самое – аллоцирует память под новый массив на каждом вызове, а массив попадает в случайную область памяти:Из этого следует, что JIT вообще никак не может заинлайнить или оптимизировать этот код, он непредсказуем и память фрагментирована. В этом суть проблемы, а не в самом переборе итератора.
А можно не выдумывать сложности там где их нет, и не пытаться оправдать существование редакса, с его уродским синтаксисом, тем, что якобы мы, решая некую там задачу – к нему же и придем.
Какой практический смысл в том, что вы преобразовали
play,pause,endedиtimeupdateвPLAYING,STOPPED,PAUSEDиENDED?Что вам это дало?
А если Vue? Angular? Solid?
Значит ли это, что при обновлении части состояния, например с PLAYING на PAUSED, пользователь это не увидет?
Чтобы что? Для чего? Да, мы знаем, что редакс подает как мегафишку то, что вообще говоря почти никогда не требуется, а если требуется, то очень легко реализуется и без него?
Поехал с сыном в Южную Корею через Пекин, прошлой весной. Тогда можно было находиться три дня без визы. Поэтому в Пекине тусили два дня, было очень интересно!
Вызвал такси, чтобы куда-то поехать, сели сзади и пристегнулись, а водитель был не пристегнут! Мы ехали по аналогу нашего третьего кольца в Москве, и считали с сыном сколько в среднем камер на каждом столбе. У нас вышло штук 8! Когда съезжали с кольца, на каком-то перекрестке были местные полицейские, и только тогда водитель пристегнулся! А удивился и спросил — а как же камеры, на что он мне ответил типа — ай ерунда, не работают.
Вторая вещь которая удивила, это решетки на всех окнах. Везде!
Какая у вас дата в календаре? У нас 10 ноября 2025)
А когда вдруг
this.users.push(user)стал антипаттерном? А, точно, когда те же ребята изобрели редакс, и продали всем идею, чтоthis.users.push({})неправильно, а правильно что-то вроде:Какая-то слабая архитектура, раз ее ломает обычный JavaScript код.
Дороговато он за это берет.
В классовом компоненте? Там запрещены хуки, а вызов метода render никак не мешает.
Тогда, когда пользователю нужно увидеть новые данные.
И? В чем именно проблема?
Или вы меня пытаетесь убедить, что
useSyncExternalStore(subscribe, getSnaphot, getServerSnapshot)удобнее чемuseSyncExternalStore(store)? Не убедили.Что? Я должен заставлять React не ломать JavaScript?
Без комментариев.
То есть, нам нужно использовать костыли
useCallbackиuseMemo, чтобы работал еще один костыль – HOCmemo, чтобы обходить ре-ренддеры возникающие из-за неравенства ссылок текущих и предыдущих пропсов возникающих вообще из-за использования хуков? Третий раз спасибо.