Привет, Дмитрий. Композишн апи был бы не так интересен, если бы дело ограничивалось семантической группировкой сущностей. Но самая вкусняшка в том, что сгруппированные "по смыслу" сущности, можно оборачивать в функции (возвращающие их), и выносить эти группирующие функции в библиотеки. И затем самые различные компоненты, могут эти вынесенные функции дёргать в своих setup'ах и с лёгкостью встраивать в себя готовые куски фунционала. На первый взгляд это похоже ...эээ... на миксины. Таки, да. Но есть небольшие, но крайне существенные различия. Во первых, в отличии от миксинов, эти [библиотечные] функции могут иметь параметры, и возращать "динамически изготовленное" (зависящее от фактических параметров) содержимое. Во вторых, их можно дёргать неоднократно, в пределах одной setup-функции (с различными или одинаковыми параметрами), чтобы создавать необходимое для компонента количество соответствующих функциональных блоков. В третьих, фактические параметры, при вызове могут быть зависимы от пропсов - миксины такого уж точно не умеют. Ну ок. А что же с реактивностью функциональных блоков, возвращаемых этими функциями ? А всё чики-пуки там с реактивностью ! Ибо третий вуй предоставляет апи реактивности, которое позволяет делать реактивными любые JS-переменные, даже если они не в однофайловых вуйских компонетах создаются. Любую библиотечную переменную можно сделать реактивной, если импортировать в либу соответсвующую "реактивизирующую" функцию вуя (например ref()), и завернуть в неё соответствующую переменную. Ну и напоследок. Вообще-то в тройке не обязательно при создании компонента делать выбор между Options API и Composition Api. Дело в том, что любой компонет может использовать ОБА апи одновременно, абсолютно без вреда для здоровья. В этом случае синаксически компонент будет написан "в стиле" Options API, а функция setup будет в нём как бы дополнительных хуком жизненного цикла. "Как бы" - потому, что есть таки некоторые тонкости, которые лучше изучить по документации, ибо место для комментариев на ютубе ограничено... -- P.S. И таки да, Дмитрий - успехов в борьбе в С.Ю.Шиповым )
Да, composition api для сложных компонентов хорошо подходит (намного проще переиспользовать код в сравнении с миксинами/наследованием + меньше проблем с реактивностью), для простых случаев вполне можно оставить options или class api - т.к. они более читабельные для простых кейсов.
Немного не затронули в варианте , случай, если мы используем props Нужно будет использовать, вот такую конструкцию, например: export default { props: { name: String } } let catName = computed(() => props.name.replace(/[_.-]/gi, ' ')) export { catName } Источник: github.com/vuejs/rfcs/blob/sfc-improvements/active-rfcs/0000-sfc-script-setup.md#using-setup-arguments
Дмитрий, теперь, когда завезли нормальную реактивность, хорошо ли будет для мелких и средних проектов хранить глобальный state приложения в $root компоненте? или тут возникнут какие-то подводные камни? (про то что отслеживания состояний как во vuex не будет - понятно, будут ли другие минусы)
Никто не разбивает компоненты, если в них 100-200 строк. Вот 600+ строк - это да. И то не всегда их стоить бить на более мелкие части. (я имею в виду компоненты, внутри которых не только логика и разметка, но и CSS).
А вот если использовать setup, и мы говорим про группировке логики, что делать есть переменные взаимосвязаны в разных частях, получается переменные придется объявлять сверху а логику групками писать ниже?
Дима, здравствуйте! есть вопрос по Вью, есть компонент, самый обычный, в нем есть data, есть methods; я попробовал переместить содержимое methods в data, было три метода, стало ноль, а дейта стала на три поля жирнее. И всё работает, никаких видимых изменений не видно. Но что будет, когда приложение станет больше, как это отразится на скорости? Очень надеюсь на твой профессиональный комментарий)
Нехватает функциональности переиспользования кусков верстки внутри одного компонента. сталкивался пару раз. вроде в 3 ничего такого не добавили. в реакте такой проблемы нет, т.к. можно разбить весь "шаблон" на отдельные переиспользуемые методы
JSX в рендер-функциях по прежнему доступен. И вполне можно выносить фрагменты шаблона в переиспользуемые методы, и накапливать их, например, в глобальной либе, а дёргать в рендер-функциях компонентов.
- хочешь присоединиться к моей религии? - что за религия ? - Лавриканство - Лаврик, как никто другой просвещает по всем темам современной веб разработки - я заинтересован! А что надо делать? - ставить в чат плюсики
Досмотрел ролик до 55-й минуты и понял главное - надо дальше изучать React.))) Такое ощущение, что во Vue одна половина сообщества пытается ставить эксперименты над второй. Не знаю, задавал ли кто-то такой вопрос раньше, но он жизненный (я с ним столкнулся после начала работы с Laravel). Как получить опыт коммерческой разработки? Вот закончил ты курсы, весь такой умный, красивый, но с нулевым портфолио никому не нужен.) А без коммерческой разработки знания бесполезны.
Наблюдал за историей развития Vue. В 1.х версии - шаблоны аля ангуляр, миксины из реакта (которые уже deprecated в реакте); 2.х - скопировали render функции из реакта. 3.х - скопировали хуки из реакта + пытаются присобачить синтаксис из svelte (script setup и ref) - получается вообще какой-то диалект js. Смотришь на все это и офигеваешь. Реакт реально проще для понимания. Ну и не типизированные шаблоны - это 5+.
У меня было так: один клиент, с которым я уже работал, обратился за веб-приложением для агрегатора предложений по организации торжественных мероприятий. Цена была крайне небольшая, если сравнивать ее с ТЗ. Я согласился, но с одним условием - стэк выбираю я сам. А мне как хотелось изучить vue и его экосистему, его я и выбрал. В итоге я учил его как раз в ходе разработки коммерческого проекта, который и в портфолию добавить не грех:)
Поменяли this на .value )) Шило на мыло... Интересно, есть ли какие-то другие подводные киллер-фичи composition API, которые бы заставили меня отказаться от кода на options API, на который даже смотреть приятней
А не надо отказываться. ОБА апи можно использовать в одном компоненте ОДНОВРЕМЕННО. Я например, так и собираюсь жить. В ролике не раскрыта важная composition-фича - возможность выносить фрагменты сходного функционала в глобальные либы, которые можно затем встраивать в компоненты посредством композиции в функциях setup. См. мой комментарий чуть выше, там немного подробнее.
@@SlavaCh Да это понятно, но правда ли это? Реакт, хуки и create react app сделали вход совсем простым. Но это холиварный вопрос, согласен. Не будем его трогать. Хотел все таки узнать как с типизацией в шаблонах? Она есть или нет?
Дмитрий спасибо за твои материалы , смотреть ролики одно удовольствие, хорошая подача, приятный голос
Дмитрий спасибо за вашу подачу, благодаря вам я нашел работу мечты!
Спасибо, самое непредвзятое видео, что я встречал. Показаны плюсы минусы и каждый уже может для себя решить, надо оно ему или нет.
Привет, Дмитрий. Композишн апи был бы не так интересен, если бы дело ограничивалось семантической группировкой сущностей. Но самая вкусняшка в том, что сгруппированные "по смыслу" сущности, можно оборачивать в функции (возвращающие их), и выносить эти группирующие функции в библиотеки. И затем самые различные компоненты, могут эти вынесенные функции дёргать в своих setup'ах и с лёгкостью встраивать в себя готовые куски фунционала.
На первый взгляд это похоже ...эээ... на миксины. Таки, да. Но есть небольшие, но крайне существенные различия. Во первых, в отличии от миксинов, эти [библиотечные] функции могут иметь параметры, и возращать "динамически изготовленное" (зависящее от фактических параметров) содержимое. Во вторых, их можно дёргать неоднократно, в пределах одной setup-функции (с различными или одинаковыми параметрами), чтобы создавать необходимое для компонента количество соответствующих функциональных блоков. В третьих, фактические параметры, при вызове могут быть зависимы от пропсов - миксины такого уж точно не умеют.
Ну ок. А что же с реактивностью функциональных блоков, возвращаемых этими функциями ? А всё чики-пуки там с реактивностью ! Ибо третий вуй предоставляет апи реактивности, которое позволяет делать реактивными любые JS-переменные, даже если они не в однофайловых вуйских компонетах создаются. Любую библиотечную переменную можно сделать реактивной, если импортировать в либу соответсвующую "реактивизирующую" функцию вуя (например ref()), и завернуть в неё соответствующую переменную.
Ну и напоследок. Вообще-то в тройке не обязательно при создании компонента делать выбор между Options API и Composition Api. Дело в том, что любой компонет может использовать ОБА апи одновременно, абсолютно без вреда для здоровья. В этом случае синаксически компонент будет написан "в стиле" Options API, а функция setup будет в нём как бы дополнительных хуком жизненного цикла. "Как бы" - потому, что есть таки некоторые тонкости, которые лучше изучить по документации, ибо место для комментариев на ютубе ограничено...
--
P.S. И таки да, Дмитрий - успехов в борьбе в С.Ю.Шиповым )
Напиши статью на хабре про все эти фишки нового вью развернуто, с удовольствием бы почитал
Да, composition api для сложных компонентов хорошо подходит (намного проще переиспользовать код в сравнении с миксинами/наследованием + меньше проблем с реактивностью), для простых случаев вполне можно оставить options или class api - т.к. они более читабельные для простых кейсов.
Дима катает в шахматы против СЮ ?
Мне понравился новый подход, он открывает новые архитектурные возможности, и позволяет удобнее работать с большими компонентами.
Спасибо, полезно. Даже через 3 года )
Дмитрий, спасибо! Красавчик!
ставлю лайк, позже посмотрю. спасибо за видос!)
телепорт реально крутая штука, реально не хватало
Спасибо
ООП - ответ на вопрос
на 48 минуте чтобы не писать .value можно же было в return обернуть объект в markRaw
Даёшь Vue 3 + TS
Я неделю убил пока c Vuex + TS разобрался. Думаю полезный контент будет. В русскоязычном сегменте ничего не нашёл такого.
Забавно, но у слайдера Swiper сейчас, всего через 2 месяца после выхода этого видео, в списке поддерживаемых версий Vue только тройка
Все таки композишн апи на любителя, а если взять тайпскрипт то можно вообще класс стайл компонент сделать и группировать как хочешь и выглядит приятно
Немного не затронули в варианте , случай, если мы используем props
Нужно будет использовать, вот такую конструкцию, например:
export default {
props: {
name: String
}
}
let catName = computed(() => props.name.replace(/[_.-]/gi, ' '))
export {
catName
}
Источник: github.com/vuejs/rfcs/blob/sfc-improvements/active-rfcs/0000-sfc-script-setup.md#using-setup-arguments
Дмитрий, теперь, когда завезли нормальную реактивность, хорошо ли будет для мелких и средних проектов хранить глобальный state приложения в $root компоненте? или тут возникнут какие-то подводные камни? (про то что отслеживания состояний как во vuex не будет - понятно, будут ли другие минусы)
Никто не разбивает компоненты, если в них 100-200 строк. Вот 600+ строк - это да. И то не всегда их стоить бить на более мелкие части. (я имею в виду компоненты, внутри которых не только логика и разметка, но и CSS).
А вот если использовать setup, и мы говорим про группировке логики, что делать есть переменные взаимосвязаны в разных частях, получается переменные придется объявлять сверху а логику групками писать ниже?
на 2 vue есть плагин для фрагментов. проблем с ним не было
Дима, здравствуйте!
есть вопрос по Вью, есть компонент, самый обычный, в нем есть data, есть methods;
я попробовал переместить содержимое methods в data, было три метода, стало ноль, а дейта стала на три поля жирнее.
И всё работает, никаких видимых изменений не видно. Но что будет, когда приложение станет больше, как это отразится на скорости?
Очень надеюсь на твой профессиональный комментарий)
Сделай видео на тему MobX vs Redux Toolkit, кто победит?
Нехватает функциональности переиспользования кусков верстки внутри одного компонента. сталкивался пару раз. вроде в 3 ничего такого не добавили. в реакте такой проблемы нет, т.к. можно разбить весь "шаблон" на отдельные переиспользуемые методы
JSX в рендер-функциях по прежнему доступен. И вполне можно выносить фрагменты шаблона в переиспользуемые методы, и накапливать их, например, в глобальной либе, а дёргать в рендер-функциях компонентов.
@@MetaDriver33 хочется без него. к тому же его нельзя смешивать с темплейтами в рамках одного компонента
переиспользуемый кусок верстки называется ... (дочерний) Компонет? )
курс по Nuxt был бы неплох)
Выкинте nuxt на помойку и забудьте как страшный сон. Используйте quasar
- хочешь присоединиться к моей религии?
- что за религия ?
- Лавриканство - Лаврик, как никто другой просвещает по всем темам современной веб разработки
- я заинтересован! А что надо делать?
- ставить в чат плюсики
Досмотрел ролик до 55-й минуты и понял главное - надо дальше изучать React.))) Такое ощущение, что во Vue одна половина сообщества пытается ставить эксперименты над второй. Не знаю, задавал ли кто-то такой вопрос раньше, но он жизненный (я с ним столкнулся после начала работы с Laravel). Как получить опыт коммерческой разработки? Вот закончил ты курсы, весь такой умный, красивый, но с нулевым портфолио никому не нужен.) А без коммерческой разработки знания бесполезны.
Досмотрел ролик до 55-й минуты и понял главное - React больше не нужен)))
И где брать этот коммерческий опыт, если все ищут спеца с опытом?))
Наблюдал за историей развития Vue. В 1.х версии - шаблоны аля ангуляр, миксины из реакта (которые уже deprecated в реакте); 2.х - скопировали render функции из реакта. 3.х - скопировали хуки из реакта + пытаются присобачить синтаксис из svelte (script setup и ref) - получается вообще какой-то диалект js. Смотришь на все это и офигеваешь. Реакт реально проще для понимания. Ну и не типизированные шаблоны - это 5+.
У меня было так: один клиент, с которым я уже работал, обратился за веб-приложением для агрегатора предложений по организации торжественных мероприятий. Цена была крайне небольшая, если сравнивать ее с ТЗ. Я согласился, но с одним условием - стэк выбираю я сам. А мне как хотелось изучить vue и его экосистему, его я и выбрал. В итоге я учил его как раз в ходе разработки коммерческого проекта, который и в портфолию добавить не грех:)
@@m0rtis-nwo, ну, я так и работаю.)
Поменяли this на .value ))
Шило на мыло... Интересно, есть ли какие-то другие подводные киллер-фичи composition API, которые бы заставили меня отказаться от кода на options API, на который даже смотреть приятней
А не надо отказываться. ОБА апи можно использовать в одном компоненте ОДНОВРЕМЕННО. Я например, так и собираюсь жить. В ролике не раскрыта важная composition-фича - возможность выносить фрагменты сходного функционала в глобальные либы, которые можно затем встраивать в компоненты посредством композиции в функциях setup. См. мой комментарий чуть выше, там немного подробнее.
@@MetaDriver33 Вот это уже другое дело. Миксины мне не особо нравятся
Зачем учить Vue, если есть Ангуляр и Реакт? :D
Зачем нужно было ждать 2020, чтобы начать работать с порталами?
С типизацией в верстке как дела?
Зачем учить Англуяр и Рякт, когда есть Vue, который в разы быстрее учится и проще в использование чем первые два?
@@SlavaCh Да это понятно, но правда ли это? Реакт, хуки и create react app сделали вход совсем простым. Но это холиварный вопрос, согласен. Не будем его трогать. Хотел все таки узнать как с типизацией в шаблонах? Она есть или нет?
@@jmmmas Vue3 адаптирован к работе с TS, отсюда следует, что типизация на месте. Или под «типизацией в шаблонах» что-то иное подразумевается?
@@SlavaCh судя по тому, что шаблоны vue - это строки, то типизация в строках отсутствует. Возможно это как то решили, интересно как?
Как обращаться к $refs в setup?
const названиеРефа = ref(null);
Это создаст template ref, тот самый. Просто во vue 3 это теперь одно и то же