Иногда в шаблоне может понадобиться временная переменная - например, в
Для этого можно использовать следующую конструкцию:
Недокументированные возможности Vue
#tip
v-for
циклеДля этого можно использовать следующую конструкцию:
<div :set="user = someLongExpression">
{{ user.firstName }} : {{ user.lastName }}
</div>
set
- это не какой-то специальный атрибут, можно использовать любое имя. Vue просто выполнит этот код в данном скоупе.Недокументированные возможности Vue
#tip
Иконки флагов стран в SVG формате - https://flagicons.lipis.dev
Можно выбрать необходимые, но если нужны все, то
#flag #svg #lib
Можно выбрать необходимые, но если нужны все, то
png
формат (sprite) может быть значительно оптимальней.#flag #svg #lib
flagicons.lipis.dev
flag-icons: Free Country Flags in SVG
A curated collection of all country flags in SVG
Автор
#volar
Volar 2 / Vue Official / Vue language tools
столкнулся с неразрешимыми проблемами при переходе на новую архитектуру, и решил откатить всё назад#volar
Telegram
Vue-FAQ
Расширение для IDE Volar проапдейтилось до версии v.2.0 и стало называться Vue - Official (название так себе для ссылок, конечно)
Много изменений и много уже зарепортировано проблем
Ушел Takeover mode, теперь расширение работает через TypeScript language…
Много изменений и много уже зарепортировано проблем
Ушел Takeover mode, теперь расширение работает через TypeScript language…
Напоминаю, что 23-24 марта 2024 будут очередные 48 часов бесплатного доступа к урокам VueSchool
Зарегистрироваться на них можно здесь
#vueschool #learning
Зарегистрироваться на них можно здесь
#vueschool #learning
vueschool.io
Vue School Free Weekend: 48 Hours of Unlimited Access
Sign up for Vue School's Free Weekend on Nov 2-3, 2024. Get unlimited access to 65+ premium Vue.js courses for 48 hours. Learn from industry experts!
Если человек долго и упорно пытается работать в open source разработке, то он либо супер классный, либо психопат
(с) Johnson Chu
На этой неделе сразу два видных контрибьютера во
Мне кажется
Эван крут, но как предприниматель явно не справляется, хотя при правильном подходе экосистема давно должна уметь себя окупать курсами, нормальными сертификациями, книгами, выступлениями, консалтингом, рекламой, инвестициями и многим другим.
#vuejs #evanyou
(с) Johnson Chu
На этой неделе сразу два видных контрибьютера во
Vue
экосистему Anthony Fu
и Johnson Chu
(автор Volar) сделали два поста о тяжести бремени работы в OSS. Первый поведал о воздействии последнего на психику, второй - также о стрессе и финансовых проблемах.Мне кажется
Vue
уже давно нужна хорошая финансовая поддержка не в виде отдельных небольших спонсорских грантов от StackBlitz
и других, а в форме грамотно спланированных бизнес-процессов и менеджмента, который помог бы обеспечить ключевых разработчиков достойной оплатой, а экосистему - развитием. Эван крут, но как предприниматель явно не справляется, хотя при правильном подходе экосистема давно должна уметь себя окупать курсами, нормальными сертификациями, книгами, выступлениями, консалтингом, рекламой, инвестициями и многим другим.
#vuejs #evanyou
Artem Zakharchenko, автор библиотеки для тестирования MSW с 15К звезд на GitHub, поделился мыслями о Test Driven Development:
TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается.
TDD подразумевает написание тестов до написания кода. Так что же в этом неправильного? Вы пишете тесты, чтобы описать намерения, стоящие за системой - как вы ожидаете, что она будет себя вести. TDD в значительной степени подразумевает, что вы должны знать, как ведет себя система, еще до ее реализации. Вы должны знать, что вы делаете.
В большинстве случаев вы этого не знаете. Все разработчики, которых я знаю, не знают этого заранее. Я не знаю этого заранее. На самом деле, я могу потратить несколько дней на эксперименты, написание MVP, пока не начну немного понимать, какими должны быть части моей системы и чего я от них ожидаю.
Я не считаю TDD жизнеспособным подходом в быстро развивающихся системах, таких как веб. Он может иметь гораздо больше смысла при написании систематического программного обеспечения, в котором очень мало что меняется от проекта к проекту. Это полная противоположность тому, что вы пишете в Интернете.
Негативный аспект TDD заключается в том, что я видел, как команды разочаровываются, если им не удается следовать ему. И тогда они отказываются от всей идеи тестирования, поскольку TDD так широко ассоциируется с ним. Вместо того чтобы поощрять людей к тестированию и показывать им, что тестирование программного обеспечения может быть интересным, эта практика запирает их в педантичных ограничениях, которым не может следовать ни один инженер.
Я не придерживаюсь TDD. Это не значит, что я не пишу тесты. Я пишу много тестов. Я занимаюсь разработкой прототипов, итераций и тестов.
Прототип. Я даю своим идеям простор и позволяю им дышать, не слишком заботясь о тестировании на первых порах. Я экспериментирую, меняю вещи, ломаю вещи, ставлю себя на место пользователя и разрабатываю API, поведение и ожидания. Как я уже сказал, это может занять некоторое время.
Итерация. Я трачу это время на то, чтобы убедиться, что моя система имеет смысл и удовлетворяет предъявляемым к ней требованиям (которые сами по себе могут развиваться и менять то, зачем я это делаю).
Тестировать. Наконец, я пишу тесты. Это стало неотъемлемой частью моего рабочего процесса. Я не могу представить себе, что не пишу тесты.
Конечно, бывают исключения. Если я пишу простую функцию ввода-вывода, то не нужно тратить день на то, чтобы понять, что она делает, потому что это все, что она будет делать. Я могу написать для нее несколько модульных тестов с самого начала. Но большинство моих (и, я уверен, ваших тоже) работ - это не простые функции. Это сложная логика, на отладку которой требуется время. Если я буду неукоснительно следовать TDD, я буду тратить время на написание тестов, которые в итоге выброшу. Это бесполезно и не поможет мне обрести уверенность в том, что я создаю.
Не отчаивайтесь. Применяйте те практики, которые работают для вас (даже если это TDD, лишь бы вы не лгали себе!). Главное, что тестирование имеет значение. Оно всегда имело значение. Разработчики тестируют программное обеспечение с 80-х годов, я полагаю. Вы тоже должны! Я сделаю все возможное, чтобы показать вам, что тестирование может быть доступным и увлекательным.
#testing #tdd #article
TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается.
TDD подразумевает написание тестов до написания кода. Так что же в этом неправильного? Вы пишете тесты, чтобы описать намерения, стоящие за системой - как вы ожидаете, что она будет себя вести. TDD в значительной степени подразумевает, что вы должны знать, как ведет себя система, еще до ее реализации. Вы должны знать, что вы делаете.
В большинстве случаев вы этого не знаете. Все разработчики, которых я знаю, не знают этого заранее. Я не знаю этого заранее. На самом деле, я могу потратить несколько дней на эксперименты, написание MVP, пока не начну немного понимать, какими должны быть части моей системы и чего я от них ожидаю.
Я не считаю TDD жизнеспособным подходом в быстро развивающихся системах, таких как веб. Он может иметь гораздо больше смысла при написании систематического программного обеспечения, в котором очень мало что меняется от проекта к проекту. Это полная противоположность тому, что вы пишете в Интернете.
Негативный аспект TDD заключается в том, что я видел, как команды разочаровываются, если им не удается следовать ему. И тогда они отказываются от всей идеи тестирования, поскольку TDD так широко ассоциируется с ним. Вместо того чтобы поощрять людей к тестированию и показывать им, что тестирование программного обеспечения может быть интересным, эта практика запирает их в педантичных ограничениях, которым не может следовать ни один инженер.
Я не придерживаюсь TDD. Это не значит, что я не пишу тесты. Я пишу много тестов. Я занимаюсь разработкой прототипов, итераций и тестов.
Прототип. Я даю своим идеям простор и позволяю им дышать, не слишком заботясь о тестировании на первых порах. Я экспериментирую, меняю вещи, ломаю вещи, ставлю себя на место пользователя и разрабатываю API, поведение и ожидания. Как я уже сказал, это может занять некоторое время.
Итерация. Я трачу это время на то, чтобы убедиться, что моя система имеет смысл и удовлетворяет предъявляемым к ней требованиям (которые сами по себе могут развиваться и менять то, зачем я это делаю).
Тестировать. Наконец, я пишу тесты. Это стало неотъемлемой частью моего рабочего процесса. Я не могу представить себе, что не пишу тесты.
Конечно, бывают исключения. Если я пишу простую функцию ввода-вывода, то не нужно тратить день на то, чтобы понять, что она делает, потому что это все, что она будет делать. Я могу написать для нее несколько модульных тестов с самого начала. Но большинство моих (и, я уверен, ваших тоже) работ - это не простые функции. Это сложная логика, на отладку которой требуется время. Если я буду неукоснительно следовать TDD, я буду тратить время на написание тестов, которые в итоге выброшу. Это бесполезно и не поможет мне обрести уверенность в том, что я создаю.
Не отчаивайтесь. Применяйте те практики, которые работают для вас (даже если это TDD, лишь бы вы не лгали себе!). Главное, что тестирование имеет значение. Оно всегда имело значение. Разработчики тестируют программное обеспечение с 80-х годов, я полагаю. Вы тоже должны! Я сделаю все возможное, чтобы показать вам, что тестирование может быть доступным и увлекательным.
#testing #tdd #article
GitHub
GitHub - mswjs/msw: Industry standard API mocking for JavaScript.
Industry standard API mocking for JavaScript. Contribute to mswjs/msw development by creating an account on GitHub.
Свершилось. Вышел VitePress 1.0.0.
VitePress - генератор статических сайтов (SSG), который удобен для создания как технических документаций, так и просто сайтов.
Больше 2 лет он был в статусе release candidate, стабильный, но постоянно добавляющий в себя функционал.
VitePress - один из трех китов империи Эвана, и обязателен к как минимум "попробовать" для любого Vue.js разработчика.
#vitepress #release
VitePress - генератор статических сайтов (SSG), который удобен для создания как технических документаций, так и просто сайтов.
Больше 2 лет он был в статусе release candidate, стабильный, но постоянно добавляющий в себя функционал.
VitePress - один из трех китов империи Эвана, и обязателен к как минимум "попробовать" для любого Vue.js разработчика.
#vitepress #release
Если в DevTools браузера вам нужна только консоль, то плагин vite-plugin-terminal позволяет выводить информацию в терминал (где запущен Vite), таким образом давая больше места странице в браузере. В VS Code его можно "отцепить" в отдельное окно.
#tip
#tip
Интересная табличка совместимости современных JavaScript рантаймов с JavaScript (сорри за мой рязанский французский)
https://runtime-compat.unjs.io
#jsre
https://runtime-compat.unjs.io
#jsre
runtime-compat.unjs.io
Runtime compatibility across JavaScript runtimes
Display APIs compatibility across different JavaScript runtimes. The data is retrieved from runtime-compat-data, based on MDN's format.
Case study о вреде Nuxt и ошибках в архитектуре
При выборе технологий для магазина Arty-Crafty я долго изучал
#nuxt #ecommerce #vuestorefront
VueStorefront
, предлагавший услуги Frontend-as-a-Service
, а именно, фронтенд для онлайн магазинов для подключения к headless e-commerce решениям, так и не смог за 4 года апгрейднуть Nuxt
со второй на третью версию и в расстроенных чувствах решил переехать на React
и Next.js
, попутно сменив название на AlokaiПри выборе технологий для магазина Arty-Crafty я долго изучал
VueStorefront
, но так и не понял, что это за зверь и с чем его едят. Теперь это проблема реактовцев.#nuxt #ecommerce #vuestorefront
GitHub
Alokai
Alokai is the Lighting-Fast Frontend Platform for Headless Commerce - Alokai
Основные функции фронтенд фреймворков
Фреймворки для веб-разработки - это, по сути, пресобранные библиотеки кода, которые обеспечивают структурированную основу для создания веб-приложений. Они предлагают целый ряд возможностей, таких как:
Компонентная архитектура: Фреймворки часто разбивают пользовательские интерфейсы на многократно используемые компоненты, что способствует модульности и удобству сопровождения.
Связывание данных (data binding): Эта функция автоматически синхронизирует данные между пользовательским интерфейсом и базовой моделью, упрощая логику и сокращая ручные манипуляции с DOM.
Маршрутизация: Фреймворки обрабатывают логику маршрутизации, обеспечивая отображение правильного контента в зависимости от навигации пользователя в приложении.
Управление состоянием: Сложные приложения иногда требуют управления состоянием различных компонентов. Фреймворки часто предоставляют встроенные или совместимые решения для этого.
Инструменты разработки (devtools): Многие фреймворки предлагают такие инструменты для разработчиков, как отладчики, горячая перезагрузка и профилирование производительности, что повышает удобство разработки.
Эти функции значительно сокращают количество шаблонизированного кода, упрощают процесс разработки и обеспечивают последовательность действий при разработке.
#frontend
Фреймворки для веб-разработки - это, по сути, пресобранные библиотеки кода, которые обеспечивают структурированную основу для создания веб-приложений. Они предлагают целый ряд возможностей, таких как:
Компонентная архитектура: Фреймворки часто разбивают пользовательские интерфейсы на многократно используемые компоненты, что способствует модульности и удобству сопровождения.
Связывание данных (data binding): Эта функция автоматически синхронизирует данные между пользовательским интерфейсом и базовой моделью, упрощая логику и сокращая ручные манипуляции с DOM.
Маршрутизация: Фреймворки обрабатывают логику маршрутизации, обеспечивая отображение правильного контента в зависимости от навигации пользователя в приложении.
Управление состоянием: Сложные приложения иногда требуют управления состоянием различных компонентов. Фреймворки часто предоставляют встроенные или совместимые решения для этого.
Инструменты разработки (devtools): Многие фреймворки предлагают такие инструменты для разработчиков, как отладчики, горячая перезагрузка и профилирование производительности, что повышает удобство разработки.
Эти функции значительно сокращают количество шаблонизированного кода, упрощают процесс разработки и обеспечивают последовательность действий при разработке.
#frontend
В CSS есть правило color-scheme для реализации цветовых тем на сайте. Не очень удобное, по сравнению с использованием для этой цели CSS переменных.
В последнем Хроме появилась экспериментальная функция
В Firefox она уже была реализована
#css #tip
В последнем Хроме появилась экспериментальная функция
light-dark
, с которой это делать проще. Но, опять же, для серьезных проектов лучше использовать CSS переменные.:root {
color-scheme: light dark;
}
.element {
color: light-dark(black, white);
background-color: light-dark(white, black);
}
В Firefox она уже была реализована
#css #tip
Одна из самых серьезных проблем в разработке программных средств — их тучность, или раздутость. Программы просто становятся слишком большими. Это может быть связано с неразумным выбором функций, но чаще всего становится следствием плохой архитектуры. Популярное средство повторного использования кода — наследование, но его работа оставляет желать лучшего, поэтому вместо него зачастую применяются копирование и вставка кода. Не следует сбрасывать со счетов и чрезмерную зависимость от библиотек, платформ и пакетов, тесно связанных со многими другими библиотеками, платформами и пакетами. Раздутость может быть побочным эффектом приемов гибкой разработки. Чтобы справиться с ней, увеличивают численность команды разработчиков, но это порождает еще большую раздутость.
…
Лучший способ справиться с раздуванием программ — не допускать его. Приоритетом при разработке и реализации программы нужно сделать ее «худобу». Следует избегать внедрения в практику раздутых пакетов и инструментов, способствующих раздуванию. Обходитесь без классов. Нанимайте небольшие квалифицированные команды разработчиков. И активно практикуйте удаление кода. Создайте резерв из нескольких циклов разработки с целью удаления ненужного кода и избавления от проблемных пакетов. Радуйтесь, когда количество строк кода в проекте уменьшается. Придерживайтесь принципа наименьшей раздутости.
(с) Дуглас Крокфорд, программист, автор формата JSON и книги "How JavaScript Works"
#quote
…
Лучший способ справиться с раздуванием программ — не допускать его. Приоритетом при разработке и реализации программы нужно сделать ее «худобу». Следует избегать внедрения в практику раздутых пакетов и инструментов, способствующих раздуванию. Обходитесь без классов. Нанимайте небольшие квалифицированные команды разработчиков. И активно практикуйте удаление кода. Создайте резерв из нескольких циклов разработки с целью удаления ненужного кода и избавления от проблемных пакетов. Радуйтесь, когда количество строк кода в проекте уменьшается. Придерживайтесь принципа наименьшей раздутости.
(с) Дуглас Крокфорд, программист, автор формата JSON и книги "How JavaScript Works"
#quote
Автор
Mucho trabajo, poco dinero...
p.s.: кстати, бетта-тестирование volar 2.0 оказывается было, и показало ошибки, которые потом вылезли и после релиза
#volar
Volar
Johnson Chu собирается покинуть open source. Стресс и слабое финансирование.Volar
(language-tools
) один из основных проектов Vue
экосистемы с точки зрения Evan You.Mucho trabajo, poco dinero...
p.s.: кстати, бетта-тестирование volar 2.0 оказывается было, и показало ошибки, которые потом вылезли и после релиза
#volar
Уже писал про esm.sh, который позволяет работать с npm ES модулями в скрипте HTML страницы. Вот его аналог - esm.run
Вот как с помощью него можно легко отрендерить markdown файл безо всяких фреймворков и генераторов:
#markdown #lib
Вот как с помощью него можно легко отрендерить markdown файл безо всяких фреймворков и генераторов:
<!doctype html>
<script type="module">
import { marked } from 'https://esm.run/marked';
document.body.innerHTML = marked(
await fetch('./README.md').then(r => r.text())
);
</script>
#markdown #lib