Оно не бесполезное, потому что апи Svelte подразумевает что только assignments are 'reactive'. Вы написали это самое присвоение и получили реактивность, не написали — не получили. Отслеживать мутации массива слишком дорого и совершенно не нужно. Более того, такой подход дает 2 плюса:
1) склоняет к иммутабильности, а значит в более точному change detection на сложных типах
2) в случае с массивом, например, позволяет синхронизировать его с отображением после нескольких мутаций (пару раз пригождалось на практике)
arr.push(1); // не обновляет DOM
arr.pop();// не обновляет DOM
arr = [ ...arr ]; // только когда мы явно этого захотели
В SvelteScript всего 4 особенности по сравнению с Javascript и они очень хорошо описаны в документации:
export creates a component prop
Assignments are 'reactive'
$: marks a statement as reactive
Prefix stores with $ to access their values
Уверен, что абсолютное большенство программистов способно запомнить эти 4 пункта. Другое дело, люди не хотят читать документацию того, чем пользуются. Что подтверждается статьями вроде Боль и слёзы в Svelte 3.
Ну и кажется, что все программисты должны понимать что такое assignments в JS. В этом смысле assignments это и есть апи, такое же как this.setState в React.
Блин, вот незадача, а в React например не работает вот так:
this.pushState({ arr: 1 });
Представляете? Безобразие я считаю, похоже реакт не стоит использовать дальше песочницы. Изучать доки и апи, я конечно же не хочу. Просто хочу чтобы работало так, как мне кажется должно работать.
Не придуривайтесь, из контекста обсуждения и так понятно, что речь про асинхронность с отпусканием ивент-лупа. Микротаски его не отпускают.
Я не читал весь тред, не так сильно интересуюсь вашими баталиями. Так то микротаски также отпускают ивент-луп после обработки кью, но вы наверное про гарантирование 60фпс. Да этого микротаски не дают. И конечно же в можно придумать надуманных задач, когда они могут держать ивент-луп.
Если же вы про теребоньканье скроллбаром, то это не то, чем занимаются пользователи приложения. Это разумная цена за малое время открытия страницы.
Не теребоньканье, а подчеркнуто не нативный UX скроллбара. Такие скроллбары вообще использоваться нельзя. Ну и я чет на заметил чтобы страница открывалась быстрее и бандл весил меньше.
Во-первых, в Svelte рендеринг тоже асинхронный на основе микротасков либо вы вкладываете в это понятие что-то другое.
Во-вторых, я пишу про весь пример. Если супер-пупер оптимизированный фреймворк юзает в примере супер-пупер специально оптимизированные встроенные компоненты со всевозможными лениво-асинхронными-отложенно-лейаутзависимыми-вставитьсвойбазворд фичами и при этом работает существенно хуже чем тупой рендеринг всего списка в DOM и поиск по нему. До кучи ответный пример написал человек, который со Svelte познакомился ровно для этого примера. То тут ничего не надо представлять в лучшем свете, все итак очевидно.
Примерно так и подумал. Весь пример прекрасно иллюстрирует понятие оверинжениринг. В то время как Svelte использует концепцию «get rid of it». Надеюсь ваши «вторые атомы» исправляют совершенно не юзабельный список и скролл тоже.
Забавно, когда супер оптимизированные кастомный скролл, который сам по себе убог, и ленивый рендеринг списка пытаются создать иллюзию скорости, но у них это не получается даже в сравнении с тупо выводом всего списка на нативном скролле, написанным на коленке человеком который даже и не слишком сильно шарит в Svelte и просто взял его для примера:
А уж что у вас творится с биндингами это вообще караул (если что печатаю я все четко в обоих примерах, но $mol упорно пытается за меня дописать или удалить символы):
Мысль была следующая: React и даже Vue — это прежде всего UI фреймворки. Чтобы на их основе построить энтерпрайз проект, необходимо обложить их дополнительными инструментами. Ясное дело, что в экосистеме обоих фреймворков необходимые решения уже имеются, но так как они не являются непосредственной частью фреймворка, часто случаются шероховатности между версиями, да и просто в подходах. В application фреймворках, таких как Angular или Ember, все инструменты подогнаны друг под друга, сразу готовы к использованию и не требуют дополнительных манипуляций для установки и налаживания совместной работы. Хорошим примером может служить Ember Data. Боюсь столь полного и интегрированного во фреймворк решения для того же React или Vue вы не найдете.
Да, но только в Svelte у нас нет необходимости прокидывать коллбеки вообще. Как правильно все это решается ивентами и описанный вами подход скорее bad practice, так как способствует запутанности кода. Особенно если скрывать эти коллбеки внутри объектов.
В этом смысле, Svelte скорее способствует хорошему дизайну ваших приложений.
У меня возникло другое впечатление. Я много разных инструментов пробовал и пробую и знаю, что такое сырой продукт или продукт у которого маленькое сообщество и небольшая экосистема. Судя по статье в svelte дела обстоят именно так.
Опять теплое с мягким. Да и вообще можно добавить немного конкретики из статьи, чтобы можно было сделать такие выводы? Сообщество только лишь русскоязычное и только лишь в Телеграм более 1К участников — это по-вашему мало? Тогда посмотрите на сообщество Ember, для примера, хотя назвать его «сырым» язык не поворачивается.
Ваши комментарии вида «есть много роутеров, вы выбрали плохой, выбирайте лучше» лишь подтверждают мое мнение.
Не пойму, по-вашему плохо что есть много альтернативных роутеров или плохо что нет одного официального? Да и почему он должен быть, если Svelte — это чисто UI фреймворк? Имхо, когда есть выбор это скорее хорошо, чем плохо. Проблема выбора трудна, как известно, но надо этому просто учиться. В жизни пригодится, а не только во фронтенде. Да и возможность за пару минут интегрироваться любое решение тоже весьма пригождается.
Я все вижу так. Автор хотел сделать UI для админки и напрягаться как можно меньше. Встретился он с относительно новым инструментом, в котором еще не все детские проблемы решены. Автору по этому поводу стало плохо и он пошел жаловаться.
Автор не хочет напрягаться до такой степени, что даже не знает инструменты, которые якобы уже изучил. И вот вам пример:
Можно создавать свои event в компонентах и избавиться от передачи в child коллбэков функции, для коммуникации между child > parent.
Мне лично определенно понравились некоторые фишки svelte, как я писал в статье. Я бы очень хотел увидеть ивенты в Vue или чтобы через год Svelte «повзрослел».
Но ведь Custom Events это components basics во Vue. Не какой-то там advanced, а basic, понимаете? Также как и концепция «props down, events up». Мы в нашей компании разрабатываем проекты на Vue c 2015 года и сразу узнали о наличии такой фичи, потому что внимательно читали документацию и изучали best practice по конкретно этому инструменту. А тут, люди берут незнакомую штуку, не изучают потому что им неохота напрягаться и начинают за деньги пилить проекты и потом жаловаться. А мы значит должны ко всему этому относиться серьезно и кто-то со стороны, например вы, начинает к этому прислушиваться. Это нормально и профессионально по-вашему мнению?
ИМХО эту критику стоило бы рассмотреть не с позиции «автор ничего не понимает, щас мы ему все объясним и расскажем как читать документацию», а с позиции «автор может быть и мелет чепуху, но зерно истины в этом есть и где-то в Svelte есть проблемы». Такая позиции, мне кажется, намного более выигрышна в долгосрочной перспективе.
Тут могу лишь отметить, что виной тому даже не лень автора, а то что, к сожалению, фреймворка сейчас во многом копируют концепции реакта и создается впечатление что «ничто не ново под луной» и можно бездумно перелазить с одного инструмента на другой не меняя подходы и привычки, а просто выучивая новый синтаксис директив и тп.
В Svelte, при том что он тоже похож на React во многом, так просто не получается сделать, из-за особого подхода ко многим вещами. Мы тоже проходили через это, когда приходится искать новые подходы и решения, которые при этом получаются значительно элегантнее и лаконичнее. В этом и есть сила Svelte, но это и не дает некоторым взять его снаскока, просто имея на плечами React/Vue и это же двигает фронтенд на шаг вперед.
Поймите, я не юзер Svelte, но такие статьи не помогают мне сделать выбор в его пользу. Как раз наоборот, они меня пугают, по принципу нет дыма без огня.
Нет, просто вы наверное не уловили контекст идущий из оригинальной статьи. Там речь про полноценные стили компонента, а не про применение классов или отдельных css правил. Во Vue и Svelte компоненты — это завершённые изолированные единицы, так называемые SFC. В React этот концепт немного недоделан из-за отсутствия работы со стилями.
В React это не будет работать. При условии, конечно, что в render будут использоваться this.loading/this.pins, и это не константы.
Нигде это условие не упоминалось, поэтому это будет работать. ))) Мы не знаем точное условие задачи. В целом, свои решения я предоставил.
К счастью хуки сделали render prop ненужным.
Недавно в одном из телеграм чатов, мне один товарищ, с пеной у рта доказывал что render props — это вообще лучшее в реакт. Гыг, я тут согласен с вами конечно.
Итого. Конвенция не везде стопроцентно строгая. Зачастую многословная (до хуков особенно). Но она есть. И часто без нее компонент просто не будет работать.
Но весь я специально привел хуки в пример. Потому что по-большому счету хуки двигают React стейт менеджмент в сторону Svelte, а не наоборот. Просто в Svelte это уже следующая ступень. React, из-за своей рантайм природы, просто не может себе этого позволить.
В Angular всё еще строже.
Тут не поспоришь, но, вот лично мне, оно так строго не надо.
Да, расширение компонентов через механизм наследования не предусмотрено, только по средствам композиции. Сделано специально, можно сказать design intent.
Просто имхо, это не плохо, а один из вариантов. Часто довольно удобный.
Понимаете, просто в Svelte такие вещи пишутся за 5-10 минут и поэтому вообще не вызывают каких-то вопросов. Вот например, пример реализации работы с объектом стилей за 3 минуты через экшн:
<h1 use:asStyled={styles}>Hello {name}!</h1>
<script>
import asStyled from './asStyled.js';
let name = 'world';
let color = 'red';
let fontSize = 16;
let sizeUnit = 'px';
$: styles = {
'font-size': fontSize + sizeUnit,
color
};
</script>
1) склоняет к иммутабильности, а значит в более точному change detection на сложных типах
2) в случае с массивом, например, позволяет синхронизировать его с отображением после нескольких мутаций (пару раз пригождалось на практике)
1) All three sections — script, styles and markup — are optional.. Очевидно в этом случае последовательность не может быть важна.
2) A capitalised tag, such as Widget or Namespace.Widget, indicates a component.
3, 4) Скорее всего вы ошиблись, хотя если сможете воспроизвести такое поведение в REPL будем благодарны за репорт.
Уверен, что абсолютное большенство программистов способно запомнить эти 4 пункта. Другое дело, люди не хотят читать документацию того, чем пользуются. Что подтверждается статьями вроде Боль и слёзы в Svelte 3.
Ну и кажется, что все программисты должны понимать что такое assignments в JS. В этом смысле assignments это и есть апи, такое же как this.setState в React.
Представляете? Безобразие я считаю, похоже реакт не стоит использовать дальше песочницы. Изучать доки и апи, я конечно же не хочу. Просто хочу чтобы работало так, как мне кажется должно работать.
Функциональность как-то влияет на адекватность работы списка и поиска?
Я не читал весь тред, не так сильно интересуюсь вашими баталиями. Так то микротаски также отпускают ивент-луп после обработки кью, но вы наверное про гарантирование 60фпс. Да этого микротаски не дают. И конечно же в можно придумать надуманных задач, когда они могут держать ивент-луп.
Не теребоньканье, а подчеркнуто не нативный UX скроллбара. Такие скроллбары вообще использоваться нельзя. Ну и я чет на заметил чтобы страница открывалась быстрее и бандл весил меньше.
Во-вторых, я пишу про весь пример. Если супер-пупер оптимизированный фреймворк юзает в примере супер-пупер специально оптимизированные встроенные компоненты со всевозможными лениво-асинхронными-отложенно-лейаутзависимыми-вставитьсвойбазворд фичами и при этом работает существенно хуже чем тупой рендеринг всего списка в DOM и поиск по нему. До кучи ответный пример написал человек, который со Svelte познакомился ровно для этого примера. То тут ничего не надо представлять в лучшем свете, все итак очевидно.
А уж что у вас творится с биндингами это вообще караул (если что печатаю я все четко в обоих примерах, но $mol упорно пытается за меня дописать или удалить символы):
В этом смысле, Svelte скорее способствует хорошему дизайну ваших приложений.
Сравниваете теплое с мягким. Попробуйте Svelte после Angular и ощущения будут точно такие же.
Ваше право, но большая часть людей с которыми я общался на тему Svelte отмечают наиболее низкий порог входа среди всех фреймворков. Также можете почитать для интереса Почему SvelteJS возможно лучший фреймворк для новых веб-разработчиков.
Опять теплое с мягким. Да и вообще можно добавить немного конкретики из статьи, чтобы можно было сделать такие выводы? Сообщество только лишь русскоязычное и только лишь в Телеграм более 1К участников — это по-вашему мало? Тогда посмотрите на сообщество Ember, для примера, хотя назвать его «сырым» язык не поворачивается.
Не пойму, по-вашему плохо что есть много альтернативных роутеров или плохо что нет одного официального? Да и почему он должен быть, если Svelte — это чисто UI фреймворк? Имхо, когда есть выбор это скорее хорошо, чем плохо. Проблема выбора трудна, как известно, но надо этому просто учиться. В жизни пригодится, а не только во фронтенде. Да и возможность за пару минут интегрироваться любое решение тоже весьма пригождается.
Автор не хочет напрягаться до такой степени, что даже не знает инструменты, которые якобы уже изучил. И вот вам пример:
Но ведь Custom Events это components basics во Vue. Не какой-то там advanced, а basic, понимаете? Также как и концепция «props down, events up». Мы в нашей компании разрабатываем проекты на Vue c 2015 года и сразу узнали о наличии такой фичи, потому что внимательно читали документацию и изучали best practice по конкретно этому инструменту. А тут, люди берут незнакомую штуку, не изучают потому что им неохота напрягаться и начинают за деньги пилить проекты и потом жаловаться. А мы значит должны ко всему этому относиться серьезно и кто-то со стороны, например вы, начинает к этому прислушиваться. Это нормально и профессионально по-вашему мнению?
Тут могу лишь отметить, что виной тому даже не лень автора, а то что, к сожалению, фреймворка сейчас во многом копируют концепции реакта и создается впечатление что «ничто не ново под луной» и можно бездумно перелазить с одного инструмента на другой не меняя подходы и привычки, а просто выучивая новый синтаксис директив и тп.
В Svelte, при том что он тоже похож на React во многом, так просто не получается сделать, из-за особого подхода ко многим вещами. Мы тоже проходили через это, когда приходится искать новые подходы и решения, которые при этом получаются значительно элегантнее и лаконичнее. В этом и есть сила Svelte, но это и не дает некоторым взять его снаскока, просто имея на плечами React/Vue и это же двигает фронтенд на шаг вперед.
Легко же: NH₃+HCl=NH₄Cl
Нигде это условие не упоминалось, поэтому это будет работать. ))) Мы не знаем точное условие задачи. В целом, свои решения я предоставил.
Недавно в одном из телеграм чатов, мне один товарищ, с пеной у рта доказывал что render props — это вообще лучшее в реакт. Гыг, я тут согласен с вами конечно.
Но весь я специально привел хуки в пример. Потому что по-большому счету хуки двигают React стейт менеджмент в сторону Svelte, а не наоборот. Просто в Svelte это уже следующая ступень. React, из-за своей рантайм природы, просто не может себе этого позволить.
Тут не поспоришь, но, вот лично мне, оно так строго не надо.
Правда слегка устаревшая, так как там Svelte 2, но сам принцип никак не изменился. Также можете посмотреть в сторону: github.com/pngwn/svelte-adapter
Понимаете, просто в Svelte такие вещи пишутся за 5-10 минут и поэтому вообще не вызывают каких-то вопросов. Вот например, пример реализации работы с объектом стилей за 3 минуты через экшн:
И использование:
REPL