Product Radar – площадка для самопрезентации технологических проектов, стартапов и пет-проектов, российский аналог Product Hunt. Запуски происходят каждую неделю.

Чтобы проработать стратегию выступления на ней, написал веб приложение, соскребающее каждый час данные по голосованию и показывающее его в динамике. Для расчета нужного угла атаки на будущее.

Пока запустил туда Аргуса - своего телеграм бота для распознавания и обработки текста на изображениях. Кому бот понравился - просьба проголосовать (нужно залогиниться через yandex/google). Спасибо.

Читаю рецензию на фильм «Бегущий по лезвию 2049». Так интересно и захватывающе написано. Смотрю дату статьи: 2017 год. Чатботов еще не завезли...

Если у вас в Vite проекте есть данные в json файлах, то иногда удобней работать с json5 (+комментарии и переносы строк, как минимум)

Для этого надо:

1. Поставить Vite плагин vite-plugin-json5

2. Поставить расширение json5 для VS Code для подсветки синтаксиса

3. Чтобы не ругался TypeScript, прописать в index.d.ts:

declare module "*.json5" {
  const value: any;
  export default value;
}

Стало намного удобней.

Бандл не меняется.

Письмо счастья.
Непонятно только - необходимость или рекомендация

Скоро GMail заблочат?

При работе с АI инструментами к ним нужно относиться как к этим двоим с картинки - мозгов немного, но очень исполнительные.

Поэтому надо отдавать им четкие промпты и держать их в строгой узде.

Вышла Vue 3.5.0-beta.1

В ней уже есть useTemplateRef - функция, заменяющая нынешний способ определения шаблонного рефа (template ref).

Основные проблемы старой реализации - неочевидность привязки переменной в скрипте по имени к элементу в шаблоне и неудобство использования шаблонного рефа в composable функциях.

Теперь привязка будет по строковому ключу

Youtube всё?

Интернет провайдер Новосибирского региона

Связи между компонентом и слотом во Vue 3

В отношениях родитель-ребенок-слот содержимому слота ребенок может передавать пропсы, как указано во Vue.js документации:

<!-- <MyComponent> template -->
<div>
  <slot :text="msg"></slot>
</div>

<MyComponent v-slot="{ text }">
  {{ text }}
</MyComponent>

Часто нужно и событие из слота переслать в ребенка. Напрямую сделать это нельзя, но можно также пропсом передать слоту ссылку на метод в ребенке, который тот и вызовет по событию:

<!--   FormField   -->
<script setup>
const touched = ref(false);
</script>

<template>
  <div class="form-field">
    <slot :touch="() => { touched = true }" />
    ...    
  </div>
</template>

<!-- использование -->
<FormField v-slot="{ touch }">
  <BaseInput @input="touch()" />
</FormField>

Этот хак бывает очень полезен и не выходит за рамки правила: "Пропсы вниз, события вверх".

Источник

При попытке пользователя уйти с сайта (exit-intent), можно показывать сообщение (просьба остаться, предложение сохранить сделанные изменения и т.п.)

Вот Vue 3 композабл для этого
------

_{Telegram-канал о Vue.js и фронтенд-разработке: @vuefaq, вебсайт: Vue‑FAQ.org}

Аргументация против глобальных автоимпортов (типа тех, что в Nuxt)

1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в *.d.ts ;)

2. Это наглядно видно не только в редакторе, но и на всяких гитхабах, когда смотришь там код, с автоимпортами тебе придется гадать, откуда взялся компонент

3. Если проект вырастает во что-то большее, чем маленький пет, то количество компонентов уже не даст нормально и лампово работать с автоимпортами, если их названия будут собираться на основе папочек, где они лежат, а в больших проектах это вообще самоубийство

4. Не нужно генерировать портянку *.d.ts для того, чтобы редакторы видели их, и, как следствие, без них ты получаешь более качественный тулинг и анализ твоего кода

5. Ты уверен, что тришейкинг работает правильно и ты явно контролируешь загрузку каждого конкретного компонента в каком-либо месте, а не полагаешься на то, что за тебя это каким-то магическим образом сделает автоимпорт

6. Импорты может проставлять сама IDE, а еще их можно сворачивать в 1 строку, если визуально отвлекают

Источник

Разница между адаптивностью (слева) и отзывчивостью (справа)

Во Vue 3, чтобы выделить из компонента отдельно некий функционал с реактивным состоянием, были созданы composable функции (называемые "функциями", хотя по сути это объект созданный через js замыкание - closure).

Чтобы использовать функционал с реактивным состоянием между несколькими компонентами, можно задействовать js модули либо Pinia/Vuex сторы.

Иногда нужно нечто среднее - подобную сущность с реактивным стейтом и функционалом на нем, но используемую в нескольких связанных компонентах (например, в Tabs или каких-то виджетах), - то есть, в некотором локальном контексте. Для этого можно в общем родительском компоненте создать composable, который передать потомкам - либо через provide/inject (лучше), либо через props (не надо).

В этом случае данный реактивный объект будет жить в своем ограниченном контексте и не будет конфликтовать с оставшейся частью проекта.

// Vue 3
const app = createApp(App);
app.config.errorHandler = (err) => {
  alert(err);
};

Во Vue можно создать собственный обработчик ошибок и ворнингов для лучшей обработки ошибок для улучшения UX.

Например, вместо того, чтобы приложение падало, если ошибка не была обработана, вы можете показать специальный экран ошибки и попросить пользователя обновить страницу или сделать что-то еще.

Обработчик ворнингов работает только в dev режиме.

Вопрос-загадка:

Сколько прошло времени от первой картинки до второй?

29 и 30 июня 2024 года Certificates.dev бесплатно на 48 часов откроет доступ к тренировочным материалам на соискание ученой степени Certified Vue.js Developer.

Включает в себя теорию, задачи по кодированию и пробный экзамен.

------

Наш Telegram-канал о Vue и фронтенд-разработке: @vuefaq и вебсайт: Vue‑FAQ.org.

Во Vue 3 есть важная и нередко используемая конструкция, у которой нет имени. Это то, что обычно называют "композабл с глобальными рефами".

Но:

1. Это не композабл по определению

2. Там не обязательно рефы

3. Они не "глобальны"

В общем случае структура данного объекта - экспортируемые из ES модуля реактивные данные и функции для работы с ними.

Функционально они заменяют "сторы" Pinia. Называть их тоже stores - двусмысленно и нелогично. Вообще, молиться на "глобальный стейт" после появления идеи JavaScript signals и их всевозможных реализаций, включая Vue Reactivity API, архаично.

Мне кажется, самое подходящее название для данной конструкции - [реактивный] бизнес объект (РБО) или Vue Business Object (VBO). В них инкапсулируется логика предметной области и приложения, они не привязаны к конкретным компонентам, и по аналогии с другими языками и фреймворками, этот паттерн - Business Object, - выглядит вполне подходящим.

Техническая реализация может быть через ES классы, ES модули, closures, Pinia stores, с использованием singleton или DI.

Кроме того, позиционирование именно как "бизнес объект" будет требовать явного отделения от него презентационного и инфраструктурного слоев - работы с Backend API, например. То есть, стимулировать использование лучших практик и наработок из других сфер разработки ПО, еще более переводя Vue.js из фреймворка для небольших проектов в разряд enterprise level решений.

--------------

Telegram-канал о Vue и фронтенд-разработке: @vuefaq и вебсайт: Vue‑FAQ.org.

Google Firebase сдался и добавил в свои сервисы SQL базу данных (облачную PostgreSQL) в форме Firebase Data Connect.

Пока в виде preview сервис можно попробовать бесплатно. Потом собираются брать плату и за саму базу, и за API доступа к ней.

Вряд ли Google с такими политиками сможет конкурировать с Supabase.На данный момент это две основные площадки, с которыми фронтендер или мобильный разработчик может без излишних усилий сделать удобный облачный бэкенд, как без логики (просто CRUD доступ), так и с ней (Functions), и оставаясь в рамках стандартов (не сильно привязываясь к проприетарным решениям сервисов).

Кажется, Роскомнадзору вчера впервые удалось заблокировать Outline (Shadowsocks VPN)

Сайт habr.com из РФ без VPN сильно глючит

Картинки не показываются, ссылки не кликаются. Кто кого блочит?

Одна из самых серьезных проблем в разработке программных средств — их тучность, или раздутость. Программы просто становятся слишком большими. Это может быть связано с неразумным выбором функций, но чаще всего становится следствием плохой архитектуры. Популярное средство повторного использования кода — наследование, но его работа оставляет желать лучшего, поэтому вместо него зачастую применяются копирование и вставка кода. Не следует сбрасывать со счетов и чрезмерную зависимость от библиотек, платформ и пакетов, тесно связанных со многими другими библиотеками, платформами и пакетами. Раздутость может быть побочным эффектом приемов гибкой разработки. Чтобы справиться с ней, увеличивают численность команды разработчиков, но это порождает еще большую раздутость.
…
Лучший способ справиться с раздуванием программ — не допускать его. Приоритетом при разработке и реализации программы нужно сделать ее «худобу». Следует избегать внедрения в практику раздутых пакетов и инструментов, способствующих раздуванию. Обходитесь без классов. Нанимайте небольшие квалифицированные команды разработчиков. И активно практикуйте удаление кода. Создайте резерв из нескольких циклов разработки с целью удаления ненужного кода и избавления от проблемных пакетов. Радуйтесь, когда количество строк кода в проекте уменьшается. Придерживайтесь принципа наименьшей раздутости.

Дуглас Крокфорд, программист, автор формата JSON и книги "How JavaScript Works"