Я, признаюсь, посмотрел только код автокомплита, и для себя все понял. До продакшн решения тут как пешком до луны. По большому счету, вы ничего то и не сделали.
Компонент кнопки (button) у меня уже есть в html, нет, реально, ни одной причины делать кнопку в виде веб-компонента. Большая часть остальных, типа Chip, Badge и т.д — делается несколькими строчками цсс. Ну и т.д.
Что реально нужно — автокомплит — маст хэв, только ваш готов процентов на 5, не более. Редкие и не везде нужные, но все же такие вещи, которые на цсс не сделать, например dual-range. То есть, не надо паковать то, что уже есть в хтмл в веб компоненты, надо предлагать то, чего нет.
И хотя я оцениваю решение на условные 5 из 10, в целом — плюсанул, потому что сам веб компоненты люблю, и считаю их недооцененными.
Попробуйте сделать какой-то один, но с полной поддержкой всего. Например, автокомплит должен уметь в множественных выбор, в поиск по опциям, в кастомизацию выбранных опций и самих опций + вести себя для браузера так же как инпут, то есть уметь в валидацию, в :valid, :invalid, :required :empty и тд и тп.
Я еще думаю, что сама формулировка «топовые фреймворки» странная. Что за топ? Кто его составил? По каким критериям отбирались фреймворки для этого топа?
Как это можно сделать? Чьей экспертизе мы можем доверять? Хороший код на реакте это что? Если код на хуках, и идеально соблюдены все правила реакта относительно хуков, и вообще лучшие практики использования хуков, это хороший код? А если код на реакте но вообще без хуков, а например, на мобх или kr-observable?
Да, правильно. Но не совсем по той причине, что описаны в статье. Автор пишет:
основанное на наших собственных домыслах о работе 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, пользователь это не увидет?
Чтобы были плагины в браузере для истории переходов!
Чтобы что? Для чего? Да, мы знаем, что редакс подает как мегафишку то, что вообще говоря почти никогда не требуется, а если требуется, то очень легко реализуется и без него?
Токсик! )
Только условия валидации это очень незначительно, и меняется редко, а «добавить фильтр» — наоборот.
Вам не кажется. Подано как очередная серебряная пуля, а по сути — пшик. Собственно поэтому мой комментарий выше остался без ответа.
Далеко вам до джаваскрипта))
У нас 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 плюсов, и главное, зачем им это?
Даже читать не стал, просто плюсик поставил.
Каждый раз когда приходится открывать икскод, у меня случается нервный тик!
Вопросов больше нет.
Эмм…
Вы называете ангулуляр нормальным, просто потому что ничего другого не знаете. Особенно по этому не стоит такие заявления делать.
Да, факт.
Я еще думаю, что сама формулировка «топовые фреймворки» странная. Что за топ? Кто его составил? По каким критериям отбирались фреймворки для этого топа?
Как это можно сделать? Чьей экспертизе мы можем доверять? Хороший код на реакте это что? Если код на хуках, и идеально соблюдены все правила реакта относительно хуков, и вообще лучшие практики использования хуков, это хороший код? А если код на реакте но вообще без хуков, а например, на мобх или kr-observable?
Да, правильно. Но не совсем по той причине, что описаны в статье. Автор пишет:
Но в итоге статья основывается на тех же домыслах. Давайте на примере вашего хука, посмотрим где реально проблема. Возьмем хук (я написал псевдо хук, но оригинал в реакте именно так работает):
И то как он используется:
Прочитав статью можно сделать вывод, что проблема здесь в переборе итератора, или как автор пишет:
Но это заблуждение и подмена смысла, проблема не в самом переборе итератора, а в том, что это каждый раз новый итератор. Чтобы это понять, нужно еще раз посмотреть, что именно происходит когда мы используем
useState(в обратном порядке):Аллоцирем память под новый массив, который каждый раз попадает в случайную область памяти.
Вызываем функцию
useState, которая возвращая нам массив – делает тоже самое – аллоцирует память под новый массив на каждом вызове, а массив попадает в случайную область памяти:Из этого следует, что JIT вообще никак не может заинлайнить или оптимизировать этот код, он непредсказуем и память фрагментирована. В этом суть проблемы, а не в самом переборе итератора.
А можно не выдумывать сложности там где их нет, и не пытаться оправдать существование редакса, с его уродским синтаксисом, тем, что якобы мы, решая некую там задачу – к нему же и придем.
Какой практический смысл в том, что вы преобразовали
play,pause,endedиtimeupdateвPLAYING,STOPPED,PAUSEDиENDED?Что вам это дало?
А если Vue? Angular? Solid?
Значит ли это, что при обновлении части состояния, например с PLAYING на PAUSED, пользователь это не увидет?
Чтобы что? Для чего? Да, мы знаем, что редакс подает как мегафишку то, что вообще говоря почти никогда не требуется, а если требуется, то очень легко реализуется и без него?