Комментарии 20
Спасибо за статью.
Svelte действительно интересный фреймворк.
Но, справедливости ради, надо заметить, что цель статьи, на которую вы отвечаете, была не в том чтобы максимально просто решить задачу, а показать как пользоваться такими инструментами как React, RxJS 6 и Recompose.
Svelte действительно интересный фреймворк.
Но, справедливости ради, надо заметить, что цель статьи, на которую вы отвечаете, была не в том чтобы максимально просто решить задачу, а показать как пользоваться такими инструментами как React, RxJS 6 и Recompose.
Спасибо, рад что вы заинтересовались.))
По второй части, согласен с вами. Однако считаю, что оригинальная статья своей цели не достигла. Кейс, который был выбран, ни в коей мере не показывает зачем использовать подобную связку инструментов. После прочтения возникает ощущение нецелесообразности происходящего и несоответствия решения задаче. Считаю, что автору оригинальной статьи следовало найти более подходящий кейс, где подобная связка имела бы смысл. Уверен, что такой кейс существует.
Целью моей статьи также не является максимально простое решение задачи. Простота и лаконичность — это скорее побочный эффект использования простых подходов и технологий, таких как Svelte. Если же изначально выбирать сложные инструменты, такие как RxJS в данном случае, то ожидать простого решения не приходится.
По второй части, согласен с вами. Однако считаю, что оригинальная статья своей цели не достигла. Кейс, который был выбран, ни в коей мере не показывает зачем использовать подобную связку инструментов. После прочтения возникает ощущение нецелесообразности происходящего и несоответствия решения задаче. Считаю, что автору оригинальной статьи следовало найти более подходящий кейс, где подобная связка имела бы смысл. Уверен, что такой кейс существует.
Целью моей статьи также не является максимально простое решение задачи. Простота и лаконичность — это скорее побочный эффект использования простых подходов и технологий, таких как Svelte. Если же изначально выбирать сложные инструменты, такие как RxJS в данном случае, то ожидать простого решения не приходится.
Спасибо за обзор. Фреймворк похож на vue.js. Можете подсказать отличия и преимущества, если знакомы с vue?
Фреймворк похож на vue.js.
Визуально да, похож. Хотя смотря с какой стороны посмотреть. Скорее уж Vue похож на Svelte. По крайней мере те подходы, которые перекочевали с Vue 1.0. Сейчас там полно из React и даже Angular.
Можете подсказать отличия и преимущества, если знакомы с vue?
Конечно знаком, пишу на нем с 2015 года. Главное отличие в том, что Svelte — это «исчезающий» фреймворк, то есть фрейморк без рантайма. Кроме того это еще статический анализатор и компилятор в ванилу.
Более подробно можете почитать об этом в других статьях про Svelte.
Тоже неплохо
Просто отлично! Всегда раздражают статьи про реакт, куда все стараются напихать КУЧУ умных слов, зависимостей и концепций… Просто чтобы сделать вот также, как получилось у вас, только ТРУ-функционально и умно. Ваш подход мне нравится гораздо больше! :)
Что-то $mol остаёт. Раньше товарищ Дмитрий любил реализовывать любые вещи на своём моле. Энтузиазм пропал, но равновесие не нарушено, так как теперь у нас есть Svelte!) Который, к слову, выглядит более адекватным)
Что-то $mol остаёт. Раньше товарищ Дмитрий любил реализовывать любые вещи на своём моле.
Да, я раньше даже специальные Disclaimer писал по этому поводу))))
Энтузиазм пропал, но равновесие не нарушено, так как теперь у нас есть Svelte!) Который, к слову, выглядит более адекватным)
Рад что вы это заметили) Вообще, равновесие еще долго будет нарушено, потому что кол-во статей о фреймворках из «Больной Тройки» нам еще долго не уравновесить))
Но признаюсь честно, написал эту статью в том числе из корыстных побуждений… В следующей статье буду интегрировать этот Svelte компонент, аля виджет, в React приложение))) Давно обещаю ребятам в чате рассказать как это делается.
Обалденно, я уже влюбился в простоту фреймворка, хотя почти ничего не знаю о нём. Но за статью спасибо, подход просто эпичный по своей простоте и одновременному решению всех проблем.
Да, а весь юмор статьи в том, что использовалась непонятная хрень в которой никто не будет разбираться. Был бы ванильный JS, то тогда было бы другое дело.
5 лет назад реакт был «непонятной хренью в которой никто не будет разбираться». А числа предлагалось складывать с помощью специального jQuery-плагина )))))
Вы бы сперва в телеграм канал заглянули к нам, прежде чем делать такие выводы.
А вообще во все времена были и будут люди, которые не хотят разбираться с чем-то новым. Однако прогресс это не остановило, как видите)))
Вы бы сперва в телеграм канал заглянули к нам, прежде чем делать такие выводы.
А вообще во все времена были и будут люди, которые не хотят разбираться с чем-то новым. Однако прогресс это не остановило, как видите)))
А как решается проблема «накладывания» промисов? Имею ввиду гипотетический сценарий, когда(даже с учетом дебаунса) отправляется несколько запросов с небольшим интервалом, и более ранний завершается позже, таким образом показываются устаревшие данные.
Решается поиском в npm по ключевым словам «debounce promise». )))))
Ок, объясню подробнее.
Юзер начинает что-то вводить, через 100мс идет первый запрос, он продолжает ввод, через 200 мс сработает второй запрос. Возможна ситуация, что первый запрос закончится позже второго и будут показаны устаревшие данные.
См. диаграмму потоков:
Код, симулирующий такую ситуацию: jsfiddle.net/mikolalex/fvau6s51/6
Ситуация, кстати, не гипотетическая, а очень часто встречающаяся на практике(медленный интернет), сталкивался на многих сайтах, например на Яндекс.Расписаниях(«запаздывающий» автокомплит названия станции).
Юзер начинает что-то вводить, через 100мс идет первый запрос, он продолжает ввод, через 200 мс сработает второй запрос. Возможна ситуация, что первый запрос закончится позже второго и будут показаны устаревшие данные.
См. диаграмму потоков:
time(ms): 0---------100-------200-------300-------400-------500-------
user
input: "q"--"qu"--"qua"--"quan"--"quant"---------------------------
promise: -----------P---------------P--------------------------------
("qua") ("quant")
\ \
\ \_GET____
\ \
request: \________GET____________\___________
\ \
resolve: ---------------------------------------"quant"------"qua"---
Код, симулирующий такую ситуацию: jsfiddle.net/mikolalex/fvau6s51/6
Ситуация, кстати, не гипотетическая, а очень часто встречающаяся на практике(медленный интернет), сталкивался на многих сайтах, например на Яндекс.Расписаниях(«запаздывающий» автокомплит названия станции).
Мне показалось или вы на полном серьезе объясняете мне что такое «гонки»? )))) Право, не стоит, вы слишком любезны. ))))
По существу вопроса, при используемом подходе «гонок» быть не может по определению, потому что вне зависимости от последовательности завершения асинхронных вызовов, стартуют они всегда в строгом порядке и синхронно. Промис созданный на последний введенный пользователем символ всегда будет последним промисом в серии вызовов. Все остальные промисы и их результаты просто отбрасываются, вне зависимости от того, в какой последовательности они завершились:
svelte.technology/repl?version=2.9.11&gist=85e212d7065e1d1c076ab2d6f341bf9b
По существу вопроса, при используемом подходе «гонок» быть не может по определению, потому что вне зависимости от последовательности завершения асинхронных вызовов, стартуют они всегда в строгом порядке и синхронно. Промис созданный на последний введенный пользователем символ всегда будет последним промисом в серии вызовов. Все остальные промисы и их результаты просто отбрасываются, вне зависимости от того, в какой последовательности они завершились:
svelte.technology/repl?version=2.9.11&gist=85e212d7065e1d1c076ab2d6f341bf9b
Достаточно запоминать последнее успешное завершение запроса в серии однотипных запросов, чтобы суметь проигнорировать «опоздавшие» результаты:
jsfiddle.net/fvau6s51/13
jsfiddle.net/fvau6s51/13
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сделать поиск пользователей по GitHub без React + RxJS 6 + Recompose