Привет, Дмитрий. Композишн апи был бы не так интересен, если бы дело ограничивалось семантической группировкой сущностей. Но самая вкусняшка в том, что сгруппированные "по смыслу" сущности, можно оборачивать в функции (возвращающие их), и выносить эти группирующие функции в библиотеки. И затем самые различные компоненты, могут эти вынесенные функции дёргать в своих setup'ах и с лёгкостью встраивать в себя готовые куски фунционала. На первый взгляд это похоже ...эээ... на миксины. Таки, да. Но есть небольшие, но крайне существенные различия. Во первых, в отличии от миксинов, эти [библиотечные] функции могут иметь параметры, и возращать "динамически изготовленное" (зависящее от фактических параметров) содержимое. Во вторых, их можно дёргать неоднократно, в пределах одной setup-функции (с различными или одинаковыми параметрами), чтобы создавать необходимое для компонента количество соответствующих функциональных блоков. В третьих, фактические параметры, при вызове могут быть зависимы от пропсов - миксины такого уж точно не умеют. Ну ок. А что же с реактивностью функциональных блоков, возвращаемых этими функциями ? А всё чики-пуки там с реактивностью ! Ибо третий вуй предоставляет апи реактивности, которое позволяет делать реактивными любые JS-переменные, даже если они не в однофайловых вуйских компонетах создаются. Любую библиотечную переменную можно сделать реактивной, если импортировать в либу соответсвующую "реактивизирующую" функцию вуя (например ref()), и завернуть в неё соответствующую переменную. Ну и напоследок. Вообще-то в тройке не обязательно при создании компонента делать выбор между Options API и Composition Api. Дело в том, что любой компонет может использовать ОБА апи одновременно, абсолютно без вреда для здоровья. В этом случае синаксически компонент будет написан "в стиле" Options API, а функция setup будет в нём как бы дополнительных хуком жизненного цикла. "Как бы" - потому, что есть таки некоторые тонкости, которые лучше изучить по документации, ибо место для комментариев на ютубе ограничено... -- P.S. И таки да, Дмитрий - успехов в борьбе в С.Ю.Шиповым )
Да, composition api для сложных компонентов хорошо подходит (намного проще переиспользовать код в сравнении с миксинами/наследованием + меньше проблем с реактивностью), для простых случаев вполне можно оставить options или class api - т.к. они более читабельные для простых кейсов.
А вот если использовать setup, и мы говорим про группировке логики, что делать есть переменные взаимосвязаны в разных частях, получается переменные придется объявлять сверху а логику групками писать ниже?
Дмитрий, теперь, когда завезли нормальную реактивность, хорошо ли будет для мелких и средних проектов хранить глобальный state приложения в $root компоненте? или тут возникнут какие-то подводные камни? (про то что отслеживания состояний как во vuex не будет - понятно, будут ли другие минусы)
Дима, здравствуйте! есть вопрос по Вью, есть компонент, самый обычный, в нем есть data, есть methods; я попробовал переместить содержимое methods в data, было три метода, стало ноль, а дейта стала на три поля жирнее. И всё работает, никаких видимых изменений не видно. Но что будет, когда приложение станет больше, как это отразится на скорости? Очень надеюсь на твой профессиональный комментарий)
Немного не затронули в варианте , случай, если мы используем 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
Никто не разбивает компоненты, если в них 100-200 строк. Вот 600+ строк - это да. И то не всегда их стоить бить на более мелкие части. (я имею в виду компоненты, внутри которых не только логика и разметка, но и CSS).
Нехватает функциональности переиспользования кусков верстки внутри одного компонента. сталкивался пару раз. вроде в 3 ничего такого не добавили. в реакте такой проблемы нет, т.к. можно разбить весь "шаблон" на отдельные переиспользуемые методы
JSX в рендер-функциях по прежнему доступен. И вполне можно выносить фрагменты шаблона в переиспользуемые методы, и накапливать их, например, в глобальной либе, а дёргать в рендер-функциях компонентов.
- хочешь присоединиться к моей религии? - что за религия ? - Лавриканство - Лаврик, как никто другой просвещает по всем темам современной веб разработки - я заинтересован! А что надо делать? - ставить в чат плюсики
Досмотрел ролик до 55-й минуты и понял главное - надо дальше изучать React.))) Такое ощущение, что во Vue одна половина сообщества пытается ставить эксперименты над второй. Не знаю, задавал ли кто-то такой вопрос раньше, но он жизненный (я с ним столкнулся после начала работы с Laravel). Как получить опыт коммерческой разработки? Вот закончил ты курсы, весь такой умный, красивый, но с нулевым портфолио никому не нужен.) А без коммерческой разработки знания бесполезны.
Наблюдал за историей развития Vue. В 1.х версии - шаблоны аля ангуляр, миксины из реакта (которые уже deprecated в реакте); 2.х - скопировали render функции из реакта. 3.х - скопировали хуки из реакта + пытаются присобачить синтаксис из svelte (script setup и ref) - получается вообще какой-то диалект js. Смотришь на все это и офигеваешь. Реакт реально проще для понимания. Ну и не типизированные шаблоны - это 5+.
У меня было так: один клиент, с которым я уже работал, обратился за веб-приложением для агрегатора предложений по организации торжественных мероприятий. Цена была крайне небольшая, если сравнивать ее с ТЗ. Я согласился, но с одним условием - стэк выбираю я сам. А мне как хотелось изучить vue и его экосистему, его я и выбрал. В итоге я учил его как раз в ходе разработки коммерческого проекта, который и в портфолию добавить не грех:)
@@SlavaCh Да это понятно, но правда ли это? Реакт, хуки и create react app сделали вход совсем простым. Но это холиварный вопрос, согласен. Не будем его трогать. Хотел все таки узнать как с типизацией в шаблонах? Она есть или нет?
Поменяли this на .value )) Шило на мыло... Интересно, есть ли какие-то другие подводные киллер-фичи composition API, которые бы заставили меня отказаться от кода на options API, на который даже смотреть приятней
А не надо отказываться. ОБА апи можно использовать в одном компоненте ОДНОВРЕМЕННО. Я например, так и собираюсь жить. В ролике не раскрыта важная composition-фича - возможность выносить фрагменты сходного функционала в глобальные либы, которые можно затем встраивать в компоненты посредством композиции в функциях setup. См. мой комментарий чуть выше, там немного подробнее.
