Привет! Долгое время спасались только вашим расширением, за что респект и спасибо! Вообще в целом сейчас все работает на удивление неплохо, хотя и не без шероховатостей. Главное что все эти тулзы получили официальную поддержку, а значит будут допиливаться. Не пробовали предложить svelteintellisence в качестве официального решения тоже?
Только для типизации пропсов или есть еще причины его использования?
Во много, имхо, это дань моде. Все вокруг пишут на TS, а значит это «must-have». Но в целом, понятное дело, что если код приложения написан на TS, а компоненты нет, то получаются пробелы в анализе и приложение не «сшивается воедино».
В названии статьи «веб-компоненты» можно было бы заменить на «кастомные элементы» — в итоге это стало единственным API, которое я использовал в проекте, и самое проработанное из всей технологии.
Спасибо за статью. Хочу вас обрадовать, вы фактически использовали весь стандарт Web components, кроме Shadow DOM. Тот же HTML Template используется внутри lit-html, который является шаблонизатором LitElement. Так что все ок. )))
Хотя это все мелочи, как именно передаются пропсы/инпуты это не важно.
Для меня важно когда фреймворк предоставляет подобие архитектуры, т.е. является фреймворком. И тут Angular вне конкуренции.
В этом вы правы, но есть один момент, который упускается из вида, потому что кто-то когда-то решил поставить в один ряд React, Vue и Angular. Хотя по-сути это не верно.
В данном случае Angular действительно вне конкуренции, просто потому что это фреймворка другого уровня. В отличии от React, Vue и Svelte, которые являеются UI фреймворками, Angular — это полноценный Application фреймворк и его имеет смысл ставить в один ряд с такие фреймворками как Ember и другими.
Показательным является то, что поверх каждого из UI фреймворков, также есть и Application фреймворк для создания сайтов и не сложных приложений. Для React это Next, для Vue — Nuxt, для Svelte — Sapper. Именно эти Application фреймворки и дают ту саму архитектуру, работу с роутингом, данными и т.п., а не только работу с view-слоем.
Ну конечно же, плагин для TypeScript подразумевает, что вы в него встраиваете другой язык, иначе в чем смысл?
Однако, можно типизировать html-шаблоны в шаблонных строках.
Svelte уже HTML-first и, как я писал выше, и мы в очередной раз выяснили, TS не дает средств работы с такими вещами. Шаблонные строки это тот же JS и никто не сомневается что TS дает работать с JS. Другое дело, что загнать любой кастомный DSL внутрь шаблонных строк тоже не получится. Это просто не удобно.
Но конечно, смысла говорить об этом с людьми, которые считают других психически больными, а сами вручную на чистом JS бегают ищут ошибки типов и думают, что автоматизация — это удел корпораций, нет, с такими людьми спорить бесполезно.
Я вам ничего плохого не писал и конкретно с вами был весьма корректен. Не нужно строить из себя Робина Гуда, пожалуйста. Это вы пришли в мою статью по той теме, которая вам не интересна. Стали отвечать на мои комментарии и давать решения, не соответствующие проблеме.
Да да, я в курсе. Кстати согласен с вашим комментарием выше. Доклад просто про React+Redux и общая конва треда про стейт внутри сторов, а Redux все еще самый популярный для React вроде. Мне самому кажется что проще застрелиться.
Вашу точку зрения я понял уже давно. В целом даже поддерживаю, особенно применительно к React. Речь по большей части про самих авторов React и то какие именно фичи они считают важными.
Кстати, ваш пример почему-то напомнил вот этот доклад. Доклад отличный, но после того как видишь насколько сложным может быть код на React + Redux для столь простого кейса, удивляешься стойкости ребят, пишущих на React.
apapacy Собственно о чем я и писал выше. Хуки в данный момент фактически самый react-way для стейта. Видимо авторы React считаю это верным способом, иначе нафиг им выкатывать большое обновление с еще один ненужным state. Хотя можно было бы сразу реализовать встроенный в React стор по всем flux'aми или что у них там сейчас.
Мне наверное надо глубже изучить Language Service Plugin, но по ссылке опять же Javascript-first код, котором появился кастомный синтаксис. А в Svelte у нас HTML-first код с кастомным синтаксисом и кажется в этом одно из основных отличий. Если опять ошибаюсь, можете меня поправить. Глубоко в Language Service Plugin не смотрел.
То что реактовский state практически бесполезен а стор реализован отдельно ровно ни о чем не говорит. Т.к. state практически не используют, его просто де факто нет. А стор есть хотя и не реактовский.
На самом деле state юзают очень много кто. Да и старых проектах на state еще навалом. Сами такие время от времени разгребаем.
Проблема со стором которого нет в реакте относится не только к реакту. Это общая боль всех фрондендов.
В целом то вы все верно пишете, но у меня тогда вопрос. Если это «общая боль» и все такое, то почему Svelte поставляется со встроенным решением для стора (пусть и весьма примитивным, но зато расширяемым), а ребята из React, которые как вы думаете все понимают, вместо того, чтобы в новой версии React поставить встроенный react-way стор, предлагают для управления стейтом вовсе не стор, а хуки, которые пишутся прямо внутри рендер-функции и, несмотря на свое удобство и лаконичность, кажется довольно сильно сказываются на производительности и требуют постоянных оптимизаций (все эти memo-)? И видимо в качестве насмешки, хуки презентует автор наиболее популярного в React решения для сторов.
Я понимаю, что вы не инсайдер, но давайте попробуем хотя бы предположить почему так происходит.
state внутри компонента отбюросило меня на пару лет в изучении реакта т.к. я не понимал зачем о нужен и его использоване приводило к разным противоречивым решениям.
Я сразу написал что это так. Что впрочем не отменяет того факта, что многие проекты использовали state именно как модель. Да и Redux далеко не сразу появился. То есть по-сути, авторы React зашипили его именно со state и именно так предполагали использовать. Это потом они сами же схватились за головы и придумали Flux/Redux.
С хуками я честно говоря еще не разбирался, вообще.
А я уже успел. И важно здесь именно то, что это опять же результат мыслительной деятельности авторов React. Не сообщества, которое положим понимает что мешать модель и представление вредно, а именно core-team реакта. А значит, по-сути своей это и есть истинный react-way.
Из новшеств меня больше заинтересовала suspense которое почему-то никак не зарелизится.
Самое интересное, что suspense точно также реализуется внутри рендер-функции и за счет ее перезапуска на каждый рендер, то есть точно также лезет в представление.
Более того, есть и тикет с подробным описанием, как этого достичь в Svelte.
Да видел, но кажется там немало подводных камней.
Перспективы на поддержку Typescript в Svelte очень радужные.
Буквально час назад они стали еще более радужными, после выступления на Svelte Society Day чувака из MS, который рассказал как они попробовали Svelte на внутреннем хакатоне, как он им очень понравился. И вроде как в MS есть даже планы на нативную поддержку Svelte со стороны Typescript. Но эту информацию еще нужно проверять.
Это не React и даже не часть React, а по сути даже не часть экосистемы React. Redux/Mobx/Efector юзают и со Svelte.
С другой стороны в реакт есть свой стейт-менеджмент. Изначально setState, с недавнего времени хуки. Последние вообще в последнее время являются чуть ли не самым рекомендованным средством, а ведь они пишутся прямо в рендер-функции и дергаются при каждом ререндере.
Исходя из этого, делаем вывод, что разработчики, использующие React, в целом умны и понимают все то, о чем вы написали. Многие действительно держат представление отдельно от модели и все такое. Однако, сам по себе React никак этому не способствует, а наоборот выкатывает все больше способов менеджерить модель прямо внутри представения.
Раньше все это хотя бы было размазано по классу, его свойствам и методам. С приходом хуков все засунули в рендер-функцию, а это примерно то, о чем написал Kroid
Насколько я вижу это не дает типизацию в шаблонах. Если я не прав, может есть ссылка где с помощью этой фичи реализована поддержка любого шаблонизатора?
В каком смысле ложь? Так работают модули JS или я не прав в этом? Глобалы конечно тоже работают, но глобалы как бы bad practice, поэтому о них говорить смысла нет.
Разработчик $mol настолько суров, что рисует картинки с мемасами исключительно на $mol. ;-)
Во много, имхо, это дань моде. Все вокруг пишут на TS, а значит это «must-have». Но в целом, понятное дело, что если код приложения написан на TS, а компоненты нет, то получаются пробелы в анализе и приложение не «сшивается воедино».
Спасибо за статью. Хочу вас обрадовать, вы фактически использовали весь стандарт Web components, кроме Shadow DOM. Тот же HTML Template используется внутри lit-html, который является шаблонизатором LitElement. Так что все ок. )))
В этом вы правы, но есть один момент, который упускается из вида, потому что кто-то когда-то решил поставить в один ряд React, Vue и Angular. Хотя по-сути это не верно.
В данном случае Angular действительно вне конкуренции, просто потому что это фреймворка другого уровня. В отличии от React, Vue и Svelte, которые являеются UI фреймворками, Angular — это полноценный Application фреймворк и его имеет смысл ставить в один ряд с такие фреймворками как Ember и другими.
Показательным является то, что поверх каждого из UI фреймворков, также есть и Application фреймворк для создания сайтов и не сложных приложений. Для React это Next, для Vue — Nuxt, для Svelte — Sapper. Именно эти Application фреймворки и дают ту саму архитектуру, работу с роутингом, данными и т.п., а не только работу с view-слоем.
Svelte уже HTML-first и, как я писал выше, и мы в очередной раз выяснили, TS не дает средств работы с такими вещами. Шаблонные строки это тот же JS и никто не сомневается что TS дает работать с JS. Другое дело, что загнать любой кастомный DSL внутрь шаблонных строк тоже не получится. Это просто не удобно.
Я вам ничего плохого не писал и конкретно с вами был весьма корректен. Не нужно строить из себя Робина Гуда, пожалуйста. Это вы пришли в мою статью по той теме, которая вам не интересна. Стали отвечать на мои комментарии и давать решения, не соответствующие проблеме.
Вы можете писать что угодно, но «караван идет». В будет идти дальше.
Кстати, ваш пример почему-то напомнил вот этот доклад. Доклад отличный, но после того как видишь насколько сложным может быть код на React + Redux для столь простого кейса, удивляешься стойкости ребят, пишущих на React.
Было
Стало
Не так уж и плохо за пару дней для «непопулярного» фреймворка.
На самом деле state юзают очень много кто. Да и старых проектах на state еще навалом. Сами такие время от времени разгребаем.
В целом то вы все верно пишете, но у меня тогда вопрос. Если это «общая боль» и все такое, то почему Svelte поставляется со встроенным решением для стора (пусть и весьма примитивным, но зато расширяемым), а ребята из React, которые как вы думаете все понимают, вместо того, чтобы в новой версии React поставить встроенный react-way стор, предлагают для управления стейтом вовсе не стор, а хуки, которые пишутся прямо внутри рендер-функции и, несмотря на свое удобство и лаконичность, кажется довольно сильно сказываются на производительности и требуют постоянных оптимизаций (все эти memo-)? И видимо в качестве насмешки, хуки презентует автор наиболее популярного в React решения для сторов.
Я понимаю, что вы не инсайдер, но давайте попробуем хотя бы предположить почему так происходит.
Я сразу написал что это так. Что впрочем не отменяет того факта, что многие проекты использовали state именно как модель. Да и Redux далеко не сразу появился. То есть по-сути, авторы React зашипили его именно со state и именно так предполагали использовать. Это потом они сами же схватились за головы и придумали Flux/Redux.
А я уже успел. И важно здесь именно то, что это опять же результат мыслительной деятельности авторов React. Не сообщества, которое положим понимает что мешать модель и представление вредно, а именно core-team реакта. А значит, по-сути своей это и есть истинный react-way.
Самое интересное, что suspense точно также реализуется внутри рендер-функции и за счет ее перезапуска на каждый рендер, то есть точно также лезет в представление.
Да видел, но кажется там немало подводных камней.
Буквально час назад они стали еще более радужными, после выступления на Svelte Society Day чувака из MS, который рассказал как они попробовали Svelte на внутреннем хакатоне, как он им очень понравился. И вроде как в MS есть даже планы на нативную поддержку Svelte со стороны Typescript. Но эту информацию еще нужно проверять.
Это не React и даже не часть React, а по сути даже не часть экосистемы React. Redux/Mobx/Efector юзают и со Svelte.
С другой стороны в реакт есть свой стейт-менеджмент. Изначально setState, с недавнего времени хуки. Последние вообще в последнее время являются чуть ли не самым рекомендованным средством, а ведь они пишутся прямо в рендер-функции и дергаются при каждом ререндере.
Исходя из этого, делаем вывод, что разработчики, использующие React, в целом умны и понимают все то, о чем вы написали. Многие действительно держат представление отдельно от модели и все такое. Однако, сам по себе React никак этому не способствует, а наоборот выкатывает все больше способов менеджерить модель прямо внутри представения.
Раньше все это хотя бы было размазано по классу, его свойствам и методам. С приходом хуков все засунули в рендер-функцию, а это примерно то, о чем написал Kroid
Не знал что это работает с MAAM. Как реализовано?
В каком смысле ложь? Так работают модули JS или я не прав в этом? Глобалы конечно тоже работают, но глобалы как бы bad practice, поэтому о них говорить смысла нет.