Народ, а как вы обходите региональные ограничения при работе с API ChatGPT с российского сервера?
Кто-то уже пробовал разворачивать что-то на NativeScript Vue? Достойный аналог капаситора, или все ещё фигня?
👍1
#vue
Иногда пишешь компонент, прокидываешь в него всякие id, class, style и прочие data-*, а они куда-то теряются. А всё потому, что Vue по умолчанию не лепит эти атрибуты на все элементы подряд. Но есть нюансы 👇
Что вообще происходит?
Vue берёт все атрибуты, которые ты НЕ объявил явно в props, и добавляет их к корневому элементу твоего компонента.
👉 В итоге на кнопке окажутся и class="big red", и id="super-btn". Удобно? Удобно.
А если у меня кастомная разметка?
Если ты хочешь, чтобы атрибуты не просто свалились куда попало, а чтобы ты сам решил — кому их отдать. Тогда тебе пригодится юзать
Иногда ты вообще не хочешь, чтобы Vue сам что-то передавал. Например, если ты хочешь полный контроль. Тогда пишешь:
👉 В этом случае все атрибуты пойдут только на кнопку, а не на обёртку. Особенно полезно, если тебе важно, чтобы стили/события применялись именно к интерактивному элементу.
Важные моменты
— Всё, что не prop — это $attrs
— По умолчанию всё это идёт в корневой элемент
— Хочешь контроль — юзай
—
— Если атрибут совпадает с именем prop — он туда не попадёт
Ну и конечно читаем доку:
EN: https://vuejs.org/guide/components/attrs.html
RU: https://ru.vuejs.org/guide/components/attrs
Иногда пишешь компонент, прокидываешь в него всякие id, class, style и прочие data-*, а они куда-то теряются. А всё потому, что Vue по умолчанию не лепит эти атрибуты на все элементы подряд. Но есть нюансы 👇
Что вообще происходит?
Vue берёт все атрибуты, которые ты НЕ объявил явно в props, и добавляет их к корневому элементу твоего компонента.
<MyButton class="big red" id="super-btn" />
<!-- Внутри MyButton.vue -->
<template>
<button>Нажми</button>
</template>
👉 В итоге на кнопке окажутся и class="big red", и id="super-btn". Удобно? Удобно.
А если у меня кастомная разметка?
Если ты хочешь, чтобы атрибуты не просто свалились куда попало, а чтобы ты сам решил — кому их отдать. Тогда тебе пригодится юзать
v-bind="$attrs"
.<template>
<div>
<button>Жмек-с</buitton>
<button v-bind="$attrs">Жмак</button>
</div>
</template>
Иногда ты вообще не хочешь, чтобы Vue сам что-то передавал. Например, если ты хочешь полный контроль. Тогда пишешь:
<template>
<div class="wrapper">
<button v-bind="$attrs">Кнопка</button>
</div>
</template>
<script setup>
defineOptions({
inheritAttrs: false
})
</script>
👉 В этом случае все атрибуты пойдут только на кнопку, а не на обёртку. Особенно полезно, если тебе важно, чтобы стили/события применялись именно к интерактивному элементу.
Важные моменты
— Всё, что не prop — это $attrs
— По умолчанию всё это идёт в корневой элемент
— Хочешь контроль — юзай
inheritAttrs: false
и v-bind="$attrs"
—
$attrs
можно использовать и в setup
, и в template
— Если атрибут совпадает с именем prop — он туда не попадёт
Ну и конечно читаем доку:
EN: https://vuejs.org/guide/components/attrs.html
RU: https://ru.vuejs.org/guide/components/attrs
🔥17👍9👌2
Отус накидали про defineExpose на Хабре
https://habr.com/ru/companies/otus/articles/899344/
https://habr.com/ru/companies/otus/articles/899344/
Хабр
defineExpose() в Vue 3
Привет, Хабр! Сколько раз вы сталкивались с ситуацией, когда сделали аккуратный Vue-компонент на <script setup> , вроде всё красиво, а потом... вам внезапно нужно из родительского компонента...
👍15
Кстате, если шо у нас есть чатик тут
https://t.me/stuffy_vuejs_chat
https://t.me/stuffy_vuejs_chat
Telegram
Чат Душного Вуя
Чат о Vue.js, Nuxt.js, Pinia, Vuex, Vite и т.д.
#vuejs #vue #nuxt #vuex #pinia #вью
#vuejs #vue #nuxt #vuex #pinia #вью
О, свеженькие викли ньюз про Вуй подъехали
https://weekly-vue.news/issues/v2/157
https://weekly-vue.news/issues/v2/157
Weekly Vue News
Weekly Vue News #193 - Subscribing to State Changes in Pinia | Weekly Vue News
This weekly Vue & Nuxt newsletter gives you high-quality tips and curated content to help you become a Vue & Nuxt expert.
❤6👍2
#vue
KeepAlive во Vue 3 — теперь с бонусами 🎁
Типичный кейс:
У тебя табы или роуты, и ты хочешь, чтобы при переключении вкладки не терялись вводимые данные, скролл и т.д.
А если я хочу контролировать, что именно кешируется?
У
А ещё можно использовать
Что нового во Vue 3?
Раньше было просто: компонент либо кешировался, либо нет. А теперь у нас больше гибкости:
Новое поведение: onActivated и onDeactivated
Когда компонент попадает в KeepAlive, Vue не вызывает unmounted, как обычно. Вместо этого срабатывают хуки:
Это значит, что ты можешь спокойно ставить на паузу таймеры, отписываться от чего-то тяжёлого, останавливать анимации и т.д.
Когда не надо использовать?
— Если компонент дешёвый (рендерится быстро)
— Если тебе не важно сохранять состояние
— Если ты хочешь, чтобы он пересоздавался при каждом появлении
TL;DR:
— KeepAlive сохраняет компоненты в памяти
— Не вызывает
— Можно фильтровать компоненты через include / exclude
— Есть max — ограничитель памяти
— Работает только с одним дочерним компонентом (или <component>)
Ну и дока
RU: https://ru.vuejs.org/guide/built-ins/keep-alive
EN: https://vuejs.org/guide/built-ins/keep-alive.html
KeepAlive во Vue 3 — теперь с бонусами 🎁
KeepAlive
— это специальный компонент-обёртка, который позволяет кешировать компонент, когда он удаляется из DOM. То есть Vue его не уничтожает, а аккуратно откладывает "на потом". Это как display: none, только с сохранением всех данных, реактивности и внутреннего состояния.Типичный кейс:
У тебя табы или роуты, и ты хочешь, чтобы при переключении вкладки не терялись вводимые данные, скролл и т.д.
<KeepAlive>
<component :is="currentTabComponent" />
</KeepAlive>
А если я хочу контролировать, что именно кешируется?
У
KeepAlive
в Vue 2.1.0+ есть пропсы include
и exclude
, туда можно вписать имена компонентов:<!-- строка, разделённая запятыми -->
<KeepAlive include="a,b">
<component :is="view" />
</KeepAlive>
<!-- регулярное выражение (используйте `v-bind`) -->
<KeepAlive :include="/a|b/">
<component :is="view" />
</KeepAlive>
<!-- массив (используйте `v-bind`) -->
<KeepAlive :include="['a', 'b']">
<component :is="view" />
</KeepAlive>
А ещё можно использовать
max
, чтобы указать, сколько компонентов максимум можно держать в памяти.<KeepAlive :max="2">
<component :is="currentTabComponent" />
</KeepAlive>
Что нового во Vue 3?
Раньше было просто: компонент либо кешировался, либо нет. А теперь у нас больше гибкости:
Новое поведение: onActivated и onDeactivated
Когда компонент попадает в KeepAlive, Vue не вызывает unmounted, как обычно. Вместо этого срабатывают хуки:
onActivated(() => {
console.log('Я снова в деле!');
});
onDeactivated(() => {
console.log('Пошёл отдыхать');
});
Это значит, что ты можешь спокойно ставить на паузу таймеры, отписываться от чего-то тяжёлого, останавливать анимации и т.д.
Когда не надо использовать?
— Если компонент дешёвый (рендерится быстро)
— Если тебе не важно сохранять состояние
— Если ты хочешь, чтобы он пересоздавался при каждом появлении
TL;DR:
— KeepAlive сохраняет компоненты в памяти
— Не вызывает
unmounted
, используй onActivated
и onDeactivated
— Можно фильтровать компоненты через include / exclude
— Есть max — ограничитель памяти
— Работает только с одним дочерним компонентом (или <component>)
Ну и дока
RU: https://ru.vuejs.org/guide/built-ins/keep-alive
EN: https://vuejs.org/guide/built-ins/keep-alive.html
6👍18❤6🔥4😁1
#vue
Сегодня поболтаем про
Что делают?
Когда применять?
— Когда у тебя компонент рендерится слишком часто, и ты не понимаешь почему
— Когда ты хочешь отладить производительность
— Когда ты ковыряешь чужой (или забытый свой) код, и надо понять, откуда ноги растут
Пример использования
👉 Когда ты жмёшь кнопку, в консоль вылетит:
Что приходит в этих хуках?
Vue кидает тебе объект с такими полями:
А что полезного можно делать?
🔍 Диагностика “лишних” перерендеров
Допустим, у тебя компонент рендерится при изменении чего-то, что вообще не используется в шаблоне.
Пихаем
🧪 Логирование зависимости
Можно даже накинуть табличку с
🎛 Анализ производительности
Можно повесить счётчик, сколько раз компонент триггерился. Если там десятки вызовов при одном клике — уже подозрительно.
TL;DR:
—
—
— Полезно для дебага и оптимизации
— Использовать только в dev-режиме
Ну и дока конечно тут:
https://ru.vuejs.org/api/composition-api-lifecycle.html#onrendertracked
Сегодня поболтаем про
onRenderTracked()
и onRenderTriggered()
— штуки, которые редко используют, но зря! 🔍Что делают?
onRenderTracked
— показывает, за чем Vue следит во время рендера (что "отслеживает").onRenderTriggered
— показывает, что изменилось и вызвало повторный рендер.Когда применять?
— Когда у тебя компонент рендерится слишком часто, и ты не понимаешь почему
— Когда ты хочешь отладить производительность
— Когда ты ковыряешь чужой (или забытый свой) код, и надо понять, откуда ноги растут
Пример использования
<script setup>
import { ref, onRenderTracked, onRenderTriggered } from 'vue';
const count = ref(0);
const name = ref('Vue');
onRenderTracked((e) => {
console.log('[tracked]', e);
});
onRenderTriggered((e) => {
console.log('[triggered]', e);
});
</script>
<template>
<div>
<p>Счётчик: {{ count }}</p>
<p>Имя: {{ name }}</p>
<button @click="count++">+1</button>
</div>
</template>
👉 Когда ты жмёшь кнопку, в консоль вылетит:
[triggered] { target: ..., key: "count", type: "set" }
Что приходит в этих хуках?
Vue кидает тебе объект с такими полями:
effect
— ссылка на реактивный эффект (рендер)target
— объект, за которым следили/который сработал (ref, reactive и т.д.)key
— конкретное поле (count, name, и т.п.)type
— тип действия (get, set, add, delete, clear)oldValue
и newValue
(в triggered) — что поменялосьА что полезного можно делать?
🔍 Диагностика “лишних” перерендеров
Допустим, у тебя компонент рендерится при изменении чего-то, что вообще не используется в шаблоне.
Пихаем
onRenderTriggered
, запускаем консоль и проверяем — если key
не совпадает ни с чем в template, возможно, надо рефакторить.🧪 Логирование зависимости
Можно даже накинуть табличку с
console.table
, чтобы красиво смотреть за чем следит твой компонент.onRenderTracked((e) => {
console.table({
key: e.key,
type: e.type,
target: e.target
});
});
🎛 Анализ производительности
Можно повесить счётчик, сколько раз компонент триггерился. Если там десятки вызовов при одном клике — уже подозрительно.
TL;DR:
—
onRenderTracked
= смотри, за чем следим—
onRenderTriggered
= смотри, что изменилось и вызвало ререндер— Полезно для дебага и оптимизации
— Использовать только в dev-режиме
Ну и дока конечно тут:
https://ru.vuejs.org/api/composition-api-lifecycle.html#onrendertracked
7🔥31👍7❤2
Набор всяческих эффектных эффектов под вуй и нухт
https://www.stunningui.design/
Правда лагает что-то как мразь просто
https://www.stunningui.design/
Правда лагает что-то как мразь просто
One Tab Group
Create Stunning Websites That Stand Out
Stunning UI is a collection of interactive Tailwind CSS components built for Vue and Nuxt.
😁9
Кстати очень хорошая и годная мысль, если уж копируете код из нейронки, проверяйте его и библиотеки которые она предлагает подключить
👍3💯2😁1
Forwarded from Будни разработчика (Sergey Bekharsky)
#нытьё дня
Неожиданно, пост дедовского нытья!
Раньше мы сами выбирали библиотеки. Скачивали архивы, клали их в
Потом появились Bower, npm, yarn — и стало проще. Одной командой можно было добавить любую зависимость. Но с этой простотой пришла и новая проблема: стало слишком легко установить что-то не то.
Теперь в игру вступил ИИ. Он подсказывает код, генерирует функции, предлагает решения. Иногда вместе с ними — и зависимости:
1. LLM генерирует код, который подключает внешние пакеты — это ожидаемо.
2. Иногда эти пакеты вымышленные, они не существуют.
3. Злоумышленники это поняли и публикуют настоящие пакеты с такими "выдуманными" именами.
4. Теперь LLM генерирует код, который подключает вредоносное ПО — и оно успешно устанавливается.
ИИ не различает добро и зло. Он просто делает то, что, по его модели, «похоже на правильное решение». А злоумышленники подстраивают реальность под эту модель.
Когда всё слишком легко, слишком удобно — легко забыть, что ты ставишь, откуда и зачем. И тогда
Естественно, это не только о фронтенде. Проблеме в том или ином виде подтверждена любая система пакетов. И даже операционные системы! Кастомные репозитории не вчера придумали.
Понятное дело, что проблему частично можно исправить, добавив в промпты реальные списки пакетов или проведя хоть какой-то анализ сферы. Но это же надо думать :)
Осторожнее, котаны.
#ai #vulnerability
Неожиданно, пост дедовского нытья!
Раньше мы сами выбирали библиотеки. Скачивали архивы, клали их в
vendor
, подключали в коде. Всё было сложно, но понятно: ты знал, что именно ты ставишь, откуда оно, и зачем.Потом появились Bower, npm, yarn — и стало проще. Одной командой можно было добавить любую зависимость. Но с этой простотой пришла и новая проблема: стало слишком легко установить что-то не то.
Теперь в игру вступил ИИ. Он подсказывает код, генерирует функции, предлагает решения. Иногда вместе с ними — и зависимости:
import x from 'some-lib'
. Всё бы ничего, но...1. LLM генерирует код, который подключает внешние пакеты — это ожидаемо.
2. Иногда эти пакеты вымышленные, они не существуют.
3. Злоумышленники это поняли и публикуют настоящие пакеты с такими "выдуманными" именами.
4. Теперь LLM генерирует код, который подключает вредоносное ПО — и оно успешно устанавливается.
ИИ не различает добро и зло. Он просто делает то, что, по его модели, «похоже на правильное решение». А злоумышленники подстраивают реальность под эту модель.
Когда всё слишком легко, слишком удобно — легко забыть, что ты ставишь, откуда и зачем. И тогда
vendor
заполняется не тобой, а кем-то другим.Естественно, это не только о фронтенде. Проблеме в том или ином виде подтверждена любая система пакетов. И даже операционные системы! Кастомные репозитории не вчера придумали.
Понятное дело, что проблему частично можно исправить, добавив в промпты реальные списки пакетов или проведя хоть какой-то анализ сферы. Но это же надо думать :)
Осторожнее, котаны.
#ai #vulnerability
👍16❤1💯1
Карочи, так как я достаточно много интересуюсь AI, то решил что своё нытьё, вау и прочее надо куда то складывать, а сюда писать не по теме мне не нравится, так что встречайте очередной никому не нужный (название естественно максимально кринжовое) канал про AI. Буду писать туда потихоньку, вдруг понравится. Велкам всем желающим ❤️
https://t.me/aispoved
https://t.me/aispoved
Telegram
AIсповедь
О мире нейросетей: от генерации изображений и текста, до новостей, ИИ-инструментов и этики.
2❤7🌭4
Forwarded from Weekly Vue News (Weekly Vue News Admin)
📢 Issue 194 is Out!
I published a new issue of my weekly Vue & Nuxt newsletter.
🔗 Check it out: https://weekly-vue.news/issues/v2/158
I published a new issue of my weekly Vue & Nuxt newsletter.
🔗 Check it out: https://weekly-vue.news/issues/v2/158
Weekly Vue News
Weekly Vue News #194 - Reactive Time Ago | Weekly Vue News
This weekly Vue & Nuxt newsletter gives you high-quality tips and curated content to help you become a Vue & Nuxt expert.
4🔥3❤1
Я как бы напоминаю, вот что мы тут все ждём))
https://medium.com/vue-mastery/whats-next-for-vue-in-2025-7996d2736e79
Основные тезисы статьи:
Nuxt 4 — большинство его возможностей уже можно включить в Nuxt 3 (≥3.12) через future.compatibilityVersion = 4; дата финального релиза пока не объявлена.
Vite 6 — добавлена Environment API; в дальнейшем Rollup внутри Vite заменит более быстрый Rolldown, но пока используется прежний бандлер.
Vitest 3 — запланирован на январь 2025 г. в синхроне с Vite 6; Node API остаётся экспериментальной и станет стабильной в версии 3.1.
Pinia 3 — API не меняется, но прекращается поддержка Vue 2; работать будет только с Vue 3.
Vapor Mode — экспериментальная версия Vue без Virtual DOM; ускоряет работу при частых обновлениях, требует Composition API, доступна для тестирования в репозитории vue‑vapor.
В 2025 г. ожидается плавная эволюция экосистемы Vue: меньше изменений синтаксиса и рискoв при обновлениях, акцент на стабильность и улучшения инструментария.
https://medium.com/vue-mastery/whats-next-for-vue-in-2025-7996d2736e79
Основные тезисы статьи:
Nuxt 4 — большинство его возможностей уже можно включить в Nuxt 3 (≥3.12) через future.compatibilityVersion = 4; дата финального релиза пока не объявлена.
Vite 6 — добавлена Environment API; в дальнейшем Rollup внутри Vite заменит более быстрый Rolldown, но пока используется прежний бандлер.
Vitest 3 — запланирован на январь 2025 г. в синхроне с Vite 6; Node API остаётся экспериментальной и станет стабильной в версии 3.1.
Pinia 3 — API не меняется, но прекращается поддержка Vue 2; работать будет только с Vue 3.
Vapor Mode — экспериментальная версия Vue без Virtual DOM; ускоряет работу при частых обновлениях, требует Composition API, доступна для тестирования в репозитории vue‑vapor.
В 2025 г. ожидается плавная эволюция экосистемы Vue: меньше изменений синтаксиса и рискoв при обновлениях, акцент на стабильность и улучшения инструментария.
Medium
What’s next for Vue in 2025?
Discover the latest Vue tools and updates for 2025 to enhance your development workflow and stay ahead in the Vue ecosystem.
1🔥23❤6👍4
Forwarded from Tamerlan
Хабр
Рецензия на книгу “Изучаем Vue: основные концепции и практические паттерны”
Книга « Изучаем Vue: основные концепции и практические паттерны для современных и масштабируемых пользовательских интерфейсов » — это сжатое практическое руководство по Vue.js, ориентированное на уже...
👍5🤔4