Результаты исследования State of JavaScript за 2018 год только что были опубликованы, и поскольку мы приблизились к концу года, то сейчас самое время взглянуть на Vue.js и посмотреть, как идут дела у этого фреймворка.

Ежегодный опрос State of JavaScript, проводимый Сашей Грейф (Sacha Greif), Рафаэлем Бенит (Raphael Benitte) и Майклом Рэмбю (Michael Rambeau), изучает мнение более 20 тысяч веб-разработчиков относительно тенденциях за прошедший год. Хотя опрос не охватывает целиком всю отрасль, он, тем не менее, даёт довольно хорошую выборку и отличную исходную точку для ознакомления с состоянием Vue. Итак, о чём там говорится?

Давайте сразу перейдём к интересному — как дела у Vue? Конечно, это не соревнование, но всё же… давайте добавим результаты по React и Angular. А затем, чтобы на самом деле ответить на этот вопрос, давайте также покажем данные за прошлый год, чтобы увидеть, как результаты менялись год от года. Да, в опросе перечислены несколько других фреймворков, однако их использование существенно ниже по сравнению с большой тройкой, поэтому я исключил их.

График выглядит очень колоритно! Так что на самом деле он нам говорит? Самое важное, что использование всех троих фреймворков увеличилось за последний год. Я не буду вдаваться в подробности данных касательно React или Angular, помимо сравнения их с Vue. Есть статьи по разбору данных опроса касательно React и Angular, в этих статьях вы найдёте всю подробную информацию.

Единственное, что выделяется — это почти уже все слышали о Vue в этом году. В 2017 году около 5% респондентов сообщили, что они никогда не слышали про Vue, тогда как в этом году этот показатель стал ниже 1%.

Положительное использование увеличилось с 20% до 29% за 2018 год. Таким образом, использование Vue.js немного выше, чем Angular, и примерно половина от React (не то, что мы сравниваем). Однако… как и со всеми данными, нам нужно поместить их в контекст и соотнести с другой информацией. Vue, пожалуй, проще всего взять и начать использовать, так что эти цифры могут включать больше людей, использующих его в небольших проектах или в целях обучения. Это подтверждается мнениями разработчиков, с которыми я общался в течение прошлого года. Это вовсе не означает, что Vue не используется в реальных проектах, просто 29% людей могут включать в себя большее количество «сомневающихся», нежели чем в других фреймворках. Тем не менее, есть много людей, использующих Vue, и их число растёт.

Обратите внимание, что голоса за «heard of it, not interested (слышал об этом, но не заинтересован)» и «heard of it, would like to learn (слышал об этом и хотел бы изучить)» держались примерно на одном уровне с небольшим уменьшением. Это соответствует продолжающемуся внедрению, и со временем мы ожидаем, что большее количество людей, выбравших вариант «heard of it, would like to learn», перейдёт группе «used it (использовали его)».

Последнее, на что следует обратить внимание: людей, отметивших вариант «used it, would not use it again (использовал его и не стал бы использовать снова)» довольно мало и теперь только немного увеличился. Этот показатель ниже, чем в React, и намного ниже, чем у Angular (опять же, мы не это сравниваем). Это очень хороший знак. Люди пытаются, они используют Vue, и им он нравится.

Кто эти люди?

Обратите внимание, что следующие данные и диаграммы предназначены только для Vue-разработчиков, они не включают информацию обо всех участниках опроса.

Для опроса также приведена демографическая информация. Первый график — информация о зарплате. Он разделён по фреймворкам, нам интересен Vue, где видно, что 17% респондентов зарабатывают 100–200 тысяч долларов, а 29% зарабатывают в 50–100 тысяч. Диапазон от 50 до 200 тысяч долларов охватывает обычную зарплату разработчиков в США. Что интересно, однако, так это то, что 19% указали свою зарплату как 30–50 тысяч долларов, а 17% — 10–30 тысяч. Они могут быть из других стран с более низкой шкалой заработной платы, или они могут указывать на количество студентов, подрядчиков, занятых неполный рабочий день, или людей на других должностях, которые только переходят в разработку. Эти категории могут указывать на группу людей, которые используют Vue, но не в продакшене.

Кроме того, если вы один из немногих, кто зарабатывает более 200 тысяч долларов в год на должности разработчика на Vue, немедленно свяжитесь со мной и расскажите, как вы это делаете 😃.

Мы также предоставляем данные о размере компании по фреймворку. Здесь мы видим, что по Vue 34% людей указали, что они работают в компании с более чем 100 сотрудниками, а 20% — в компаниях с 5 или менее сотрудниками, поэтому наблюдается довольно хороший разброс в размере компании. Обратите внимание, что сочетание категорий (например, между «1–5» и «1») не было опечаткой с моей стороны, именно так перечислены результаты.

Наконец, результаты опроса содержат многолетний опыт работы с каждым фреймворком, и здесь мы видим довольно хороший рост. 30% принявших участие в опросе имеют 2–5 лет опыта, и столько же, 30%, по 5–10 лет опыта, а у 23% — 10–20 лет опыта. Менее двух лет назад было 13%, поэтому мы видим некоторый интерес начального уровня, но не такой, как у более опытных разработчиков.

Более тщательное изучение

Анализ данных относительно Vue, позволяет нам лучше понять, кто и почему используют Vue.

Начнём с того, что больше всего понравившийся аспект Vue, причиной номер один стала «плавная кривая обучения (easy learning curve)», за которой следуют «элегантный стиль программирования (elegant programming style)» и «хорошая документация (good documentation)». Другими словами, с Vue легко работать. С другой стороны, пункт «высокая производительность (fast performance)» оказался в списке на пятом месте, поэтому тем, кто используют Vue в реальных приложениях, стоит уделить внимание производительности. Следует отметить, что так ответили те участники опроса, которые указали, что использовали Vue и будут использовать его снова.

Из числа тех, кто ответил, что «использовали его и НЕ будут использовать его снова», и имейте в виду, что это очень маленький процент людей, первой причиной с огромным отрывом стал «неуклюжий стиль программирования (clumsy programming style)». Это, похоже, противоречит тем же причинам, которые нравились другой группе, и предполагает, что Vue похож на пиво со вкусом тыквы. Некоторые люди просто любят его, а другие думают, что это противно. Это вопрос стиля и предпочтений. (Для справки, люди, которые считают, что тыквенное пиво противно, правы 🙂).

Следующий интересный набор данных — это место, где находятся счастливые пользователи Vue. Самый высокий процент отмечен в Китае, Франции, Индонезии, Таиланде, Вьетнаме, Нигерии, Мексике, Перу, Бразилии и некоторых других странах. К местам с меньшим степени удовлетворённости относятся США, Индия и Австралия.

В докладе вкратце (для раздела фреймворков) указывается, что React в настоящее время является самым популярным фреймворком, а Vue неуклонно растёт. В отчёте указывается, что Vue фактически обогнал React по общему количеству звёзд на GitHub. Angular поддерживает значительную пользовательскую базу, и, хотя не все довольны им, он, кажется, хорошо вписывается в определённые ситуации и не проявляет каких-либо признаков исчезновения с лица земли.

Но подождите, это ещё не всё!

Опрос State of JavaScript даёт нам полезную информацию от большого количества разработчиков, но это не весь рынок. Он также задаёт определённые вопросы, но не всем. Существуют и другие опросы, которые стоит посмотреть, один из которых является Developer Survey Results от Stack Overflow . Или, по крайней мере, он был бы интересен для рассмотрения, если бы включал Vue, которого пока нет. Vue может расти как на дрожжах, но это не везде (пока ещё!). Обратите внимание, что на Stack Overflow есть тонна вопросов про Vue.

Опрос от Stack Overflow 2018 года включал Angular и React, а также .NET и ряд других инструментов, но не Vue. Интересно отметить, что в этом опросе Angular превосходит React как наиболее часто используемый фреймворк с 37% против 28% у React. Казалось бы, это противоречит результатам опроса State of JavaScript, где React превосходит Angular. Хотя это не имеет никакого отношения к Vue, это подчёркивает важность детального изучения данных опроса — как именно задавались вопросы? У кого был доступ к опросу? Кто завершил опросы? Это также показывает, что нужно быть осторожнее, полагаясь на результаты только одного опроса.

Я добавлю две заметки про опрос Stack Overflow. Во-первых, он было проведён в начале 2018 года, так что ему почти год. Во-вторых, я не видел фактического опроса, поэтому я (разумно) предположил, что Vue просто исключён из списка вариантов, поскольку его вообще не было в списке результатов.

Кто нанимает

Существует ряд других способов посмотреть на рост Vue. Мы можем, например, отобрать вакансии, чтобы увидеть, сколько компаний указывают «Vue» в качестве необходимого навыка в описании вакансии. Поиск по популярному сайту вакансий Indeed.com по запросу «Vue» выдаёт 2 661 вакансию, включающее слово «Vue» в описание. Большинство из них для вакансии на должность разработчика. Если мы действительно хотим получить точное число, мы должны потратить дополнительное время на фильтрацию результатов вакансий по «Vue». Я вижу одну вакансию, относящуюся к «Pearson Vue», другую к «Campus Vue», и третью — «Playstation Vue», но большинство вакансий на поиск Vue-разработчиков, и я больше хочу понять общее ощущение рынка, а не идеальное число.

Что интересно, React даёт нам 58 433 рабочих места, а Angular — 17 219. Оба результата выглядят так, как будто найденные вакансии, как правило, на поиск соответствующих разработчиков, хотя число React кажется довольно высоким, и любой детальный анализ займёт некоторое время на поиск ключевых слов для фильтрации. Также обратите внимание, что в некоторых вакансиях можно встретить фразу типа «Требуется опыт таких технологий, как React, Angular и т.д.», поэтому работодатели не обязательно ищут разработчика на React.

Несмотря на все нестыковки, которые я перечисляю, это рисует довольно чёткую картину рынка, который глубоко погружён в React, все ещё силён для Angular, и только начинает работать с Vue в продакшене. При всем этом интересе, который мы видели в других источниках, мы должны ожидать, что вакансии по Vue увеличатся в течение следующих нескольких лет, поскольку интерес переходит в использование.

Кто ищет

Google всегда хорош для определённой аналитики, поэтому мы можем воспользоваться Google Trends для отслеживания популярности Vue с течением времени на основе поисковых запросов. Здесь также нужно обратить внимание на то, как мы структурируем запрос. Просмотр графика времени говорит нам о многом, например, мы знаем, когда Vue появился на сцене (в 2014 году), поэтому, если результаты не начинаются с нуля в 2014 году, а затем стабильно растут, мы, вероятно, используем неправильные условия поиска. Мы также можем просто погуглить «”Vue”» или другие варианты и посмотреть на ранжирование, и, возможно, нам может потребоваться ещё отфильтровать поисковую выдачу.

Поиск «Vue» по трендам даёт нам хорошие результаты, начиная с 2004 года, и это, конечно, не то, что нам нужно. Поиск по трендам «Vue.js» даёт нам кривую, которая начинается в 2014 году, а затем поднимается выше, и безусловно нет какого-либо другого «Vue.js», который мог бы привести к неожиданным результатам. С другой стороны, некоторые люди могут просто искать термин «Vue», потому что его чаще сокращают. Поиск только по «Vue.js» будет скучать по таким людям 😊.

В Google Trends также интересен отчёт «interest by region (интерес по регионам)», в котором Южная Корея заняла первое место. Остров Святой Елены на втором месте, и я приветствую любые объяснения, почему это так. Япония на третьем месте и т.д. Я был бы больше взволнован результатами «Остров Святой Елены» (неточные данные?), за исключением того, что анализ трендов только для США возвращает очень похожий график. Исходя из результатов, которые мы видим здесь, Vue явно продолжает расти (и нам не хватает декабрьских данных по итогам 2018 года, что сделает его ещё выше). Люди ищут информацию по нему. Рост в 2018 году вряд ли будет соответствовать росту в 2017 году, но помните, что опрос State of JavaScript показал Vue почти с нулевым числом людей, которые не были знакомы с ним в 2018 году. Я не буду показывать сравнения с React или Angular, поскольку трудно получить точные условия поиска яблок против яблок.

Вывод

Все эти источники данных полезны в создании картины принятия Vue и его использования в реальном мире. Однако я не могу предостеречь вас достаточно сильно, чтобы каждый источник был взят за одну точку данных. Как я упоминал выше, какие именно вопросы были заданы или использовались поисковые условия, как были собраны данные, кто имел доступ, чтобы внести свой вклад и т.д. — всё это может так или иначе искажать данные. Всю картинку в целом можно получить только путём анализа несколько источников данных. И такая общая картина состоит в том, что Vue может быть номером три, но он растёт, у него уже есть сильные последователи, и это не может не радовать.

И последнее, что я хочу добавить, — это мой личный опыт участия в ряде конференций по Vue за последний год. Для начала, в прошлом году было добавлено несколько новых конференций Vue, которые собрали большое число участников. Экосистема все ещё растёт, и по мере роста будут проводиться такие виды деятельности, как различные события, и инструменты поддержки, такие как Kendo UI для Vue. Я разговаривал с несколькими разработчиками на этих хорошо посещаемых конференциях Vue, и они полны энтузиазма, и многие из них используют Vue в реальных приложениях в продакшене. Vue здесь и никуда не денется. По крайней мере, на данный момент, потому что в мире веб-приложений единственная реальная константа — это изменения.

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Если вам понравилась статья, внизу можно поддержать автора хлопками 👏🏻 Спасибо за прочтение!

Состояние JavaScript в 2018 году: обзор Vue.js was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

Присоединяйтесь к нам в октябре этого года поучаствовать в уже пятом ежегодном Hacktoberfest, событии, посвящённом месячному празднованию проектов с открытым исходным кодом (опенсорс). Как и прошлом году в организации нам помогают наши друзья из DigitalOcean, но в этому к нашему партнёрству присоединяется Twilio.

Легко приобщиться к данному веселью (и получить фирменную футболку!), Все, что вам нужно сделать, это зайти на сайт Hacktoberfest для регистрации в качестве участника. Затем отправить 5 пулреквестов в публичные репозитории опенсорс-проектов в период с 1 по 31 октября. Вот и всё! Первые 50 000 участников, которые сделают это, получат футболку лимитированную Hacktoberfest. Полные условия этой акции размещены на сайте Hacktoberfest.

Если вы никогда раньше не участвовали в опенсорс-проекте, рекомендуем вам поучаствовать в этом празднике опенсорса, а наше руководство по внесению своего вклада в опенсорс, помогут в этом.

Хотите поделиться своей любовью к Hacktoberfest? Расскажите миру о хештеге #hacktoberfest в Twitter, Facebook или Instagram.

В прошлом году более 30 000 человек из более чем 100 стран (119, если быть точным!) создали почти 240 000 пулреквестов в самые разные проекты — все, начиная от правок в документацию и исправлений ошибок вплоть до реализации новых фич и улучшений производительности. Почитайте их рассказы и (а посмотри их селфи!) в Twitter с хештегом #hacktoberfest.

Не знаете с чего начать — сделайте перевод для devSchacht!

Поскольку перевод в devSchacht делается через PR в репозитории на GitHub (не забудьте поставить звёздочку, если вам нравится наши переводы!), то мы предлагаем нашим читателям и просто желающим принять участие в Hacktoberfest, перевести какую-нибудь статью. Ниже приведён список статей, перевод которых мы хотели бы наиболее сильнее получить, однако вы можете любую, связанную с веб-разработкой статью:

1. 12 Factor CLI Apps (забронировано за Ufocoder)
2. Refactoring Node with Higher-Order Functions (переведено Ufocoder)
3. How we do Vue: one year later
4. Idiomatic Redux: The Tao of Redux, Part 2 — Practice and Philosophy
5. JavaScript typeof (переведено Ufocoder)
6. 5 reasons you shouldn’t be using GraphQL (переведено)
7. Immutability in React and Redux: The Complete Guide
8. What is Modular CSS?
9. 5 Most-Requested Features For Vue.js in 2018
10. What and How to Test with Jest and Enzyme. Full Instruction on React Components Testing (переведено)

Руководство — «Участие в переводах devSchacht»

Не стесняйтесь переводить и вообще участвовать в Hacktoberfest! 🎃

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Статья на GitHub

Hacktoberfest вернулся и празднует свой пятый год! was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

В первой статье в этой серии из пяти частей о тестировании в JavaScript мы рассмотрим, что такое тестирование и почему мы должны это делать. Если вас интересует тестирование в контексте Vue.js, то обратите внимание на книгу «Тестирование компонентов Vue.js с помощью Jest».

Тестирование в области разработки программного обеспечения — это процесс оценки того, что все части приложения ведут себя так, как ожидалось.

Тесты выполняют проверки программного обеспечения, проверяя, что полученный результат соответствует спецификациям, учитывая разные входные данные. Каждая из этих проверок называется тестовым сценарием (test case). В рабочем процессе agile каждая пользовательская история должна иметь набор тестовых сценариев. Простой пример:

US-01: создание компонента ввода валюты

Сценарии тестирования:
– TC-01: он должен принимать только числа
1. Введите число «2». Ожидается: все должно быть в порядке
2. Введите символ «a». Ожидается: должно отображаться сообщение «Разрешены только числа»
– TC02: оно не может быть пустым
...

В тестовых сценариях проверяются требования и характеристики конкретной функциональной возможности (функционала). Они могут предоставлять определённые детали или шаги, чтобы их можно было воспроизвести.

Скорее всего, если вы читаете эту статью, вы знаете, что такое тестирование и TDD, но если вы новичок в тестировании, у вас может возникнуть вопрос, который был в своё время у всех нас:

Не занимает ли тестирование слишком много времени? Нужно ли мне тестировать всё?

В этой статье мы поговорим о плюсах и минусах тестирования, о типах тестирования, и что ещё есть кроме тестирования для обеспечения качества приложения.

Зачем писать тесты?

Говоря о том, зачем нужно тестирование, можно упомянуть следующие его преимущества:

• Экономит деньги: без надлежащего тестирования количество времени и ресурсов, необходимых для поддержания продукта в долгосрочной перспективе, намного больше, чем инвестиции в тестирование, не говоря уже о том, что со временем что-то сломается.
• Обеспечивает безопасность кода при командной работе: приложение часто создаётся командами. Разные люди изменяют один и тот же фрагмент кода с течением времени. Наличие тестов делают этот процесс более безопасным, поскольку никто не сломает что-то, не узнав об этом. Это также относится и к будущему, тесты обеспечивает безопасность кода, когда вы вернётесь через год или два для внесения изменений.
• Помогает в создании лучшей архитектуры: когда часть приложения трудно тестировать, это обычно происходит из-за того, что оно тесно связано с другими частями или функциональность вашего приложения слишком сложна. При их тестировании вам нужно будет сделать их слабосвязанными, применить делегирование и паттерны проектирования, чтобы сделать приложение максимально простым и тестируемым.
• Улучшает качество кода: ваш продукт менее подвержен сбоям в работе поскольку тесты помогает написать более надёжный и хороший код, который менее подвержен ошибкам.
• Делает рефакторинг простым и безопасным: создание программного обеспечения — это итеративный процесс. Требования меняются с течением времени, следовательно, меняется и функциональность. Наличие хорошего тестового покрытия позволяет вам модифицировать определённый код, проверяя, что тесты все ещё успешно проходят. Если это не так, вы делаете правки в код таким образом, чтобы тесты прошли.

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

Типы тестов

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

У нас есть три основных типа тестов:

• End-to-end-тесты (сокращённо — E2E) или сквозные тесты, как их называют при переводе: тестируют систему в целом, эмулируя реальную пользовательскую среду. В интернете это тесты, запущенные в браузере, имитирующие щелчки мышью и нажатия клавиш. В общем, набор таких тестов не должен быть большим, так как они дороги для обслуживания и могут легко устареть из-за тестирования системы в целом.
• Интеграционные тесты: цель данных тестов состоит в том, чтобы убедиться, что несколько зависимых друг от друга модулей кода работают вместе, и их взаимодействие работает должным образом.
• Модульные тесты: они тестируют определённую функциональность изолированно. Их легче всего создавать и обслуживать, поэтому большинство тестовых наборов — это модульные тесты.

Пирамида описывает баланс различных типов тестов. Нижняя часть — это самые быстрые, простые и самые изолированные тесты, а верхние — самые дорогие, самые медленные и охватывают всё приложение в целом.

Интеграционный слой можно даже разделить на ещё большее количество слоёв:

Хотя есть несколько разногласий по поводу количества типов тестов и их имён, наиболее распространёнными являются тесты компонентов и API. Это всего лишь особые типы интеграционных тестов. В частности, тесты компонентов — это тесты, которые мы пишем на стороне фронтенда при тестировании приложения на Vue.js.

Статический анализ

Тесты — не единственный инструмент для обеспечения качества кода. В наше время для JavaScript также есть инструменты статической типизации и утилиты для проверки кода (linters, далее — линтеры). Они выполняют статический анализ вашего кода для поиска несоответствий выбранному стилю кода, неправильного использования языка, ненадлежащей и плохой практики, ошибок в контракте данных и многое другое.

Контракт данных — формат данных, который будет использоваться некоторой частью приложения, например функцией. Обычно под этим понимается в каком виде будут представлены данные, например, тип входных и возвращаемых данных.

Статическая типизация делает ваш код более безопасным на основе каждого контракта. Такие инструменты, как TypeScript или Flow, позволяют определять переменные, параметры и типы возвращаемых значений. Они гарантируют, что ваши классы, функции и методы имеют определённую структуру, а остальная часть вашего кода хорошо работает в соответствии с этим. Многие компании, принявшие статическую типизацию, сразу же поймали несколько ошибок.

Давайте сравним типизированную версию и не типизированную версию функции sum:

// Нетипизированная функция
function sum(a, b) {
    return a + b;
}

// Типизированная функция
function sum(a: number, b: number) : number {
    return a + b;
}

Версия функции без указания типов не мешает нам вызывает её со строчными входными данными, в результате возвращая нам конкатенацию строк. Например, вызов sum('1', '2') возвращает '12'. Однако, если мы используем статическую типизацию, мы получаем ошибку, такую как Argument of type '"1"' is not assignable to parameter of type 'number' (Аргумент этого типа '"1"' не может быть присвоен параметру типа 'number'), и эта ошибка типизации предотвращает нас во время компиляции совершить вызов функции, который вернёт неверный результат, поскольку мы ожидаем сложение чисел, а не конкатенацию строк.

Линтеры — это специальные программы, цель которых анализ и проверка различных аспектов кода во время компиляции. JavaScript не имеет преимуществ компилятора, поэтому подвержен ошибкам во время выполнения по сравнению с другими языками, где об ошибках будет сообщено на стадии компиляции. ESLint стал линтером де-факто в JavaScript, а TSLint — в сообществе TypeScript.

Линтер пытается заполнить пробел, предоставляя правила проверки ошибок синтаксиса, стиля кода и неправильного использования (проблемных паттернов). В результате он уменьшает количество ошибок и повышает качество и корректность вашего кода.

В качестве примера, если вы используете правило no-var в ESLint и напишите следующий код:

var greet = 'Эй, Китти';

Вы получите ошибку Unexpected var, используйте let или const вместо (no-var) (Неожиданный var, используйте let или const вместо него (no-var)).

В пирамиде статический анализ ещё точнее определён и проверяется быстрее (почти в режиме реального времени), чем модульные тесты, что делает его основой пирамиды:

Эта статья является первой частью серии Тестируй как профи в JavaScript.

Что такое тестирование и почему мы должны его делать? was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

Перевод статьи Dmitri Grabov: React is not the new JQuery.

Это был тихий субботний день, когда я столкнулся с таким постом — React is the New JQuery (React — это новый jQuery). Я чувствовал, что было довольно много недоразумений, и подумал попытаться разрешить некоторые из поднятых в статье вопросов.

Я считаю, что обсуждение инструментов с точки зрения их крутости — это пустая трата времени и сил. Каждый инструмент разработан как ответ на улучшение решения распространённых проблем. Когда мы решаем одну проблему, возникают новые, которые, в свою очередь, требуют иных инструментов. Сами инструменты не вызывают сложности, они являются реакцией на более сложную работу, которой мы пытаемся заниматься.

Цель jQuery в основном заключалась в предоставлении единообразного способа решения проблем, связанными с кроссбраузерностью, а также обеспечить мощными инструментами управления DOM. Этот подход был основан на сервере, генерирующем HTML-страницу, а затем JS загружался на фронтенде для обработки взаимодействий пользователя. Вы можете создавать переключатели или любые компоненты для расширения возможностей браузера по умолчанию. Проблема с данным подходом заключается в том, что ваш пользовательский интерфейс заканчивается тем, что реализуется через клиент и сервер. Чаще всего это означает, что нам нужно два разработчика для реализации функциональных возможностей в двух местах — и на клиенте, и на сервере. Это занимает больше времени, больше общения и, скорее всего, приведёт к багам.

Вместо того, чтобы думать о React как способе реализации компонентов, подумайте о React как о самом пользовательском интерфейсе. Мы можем собрать пользовательский интерфейс из повторно используемых компонентов, которые создаём по ходу работы над приложением. Мы можем выполнять код таким же образом на сервере, как мы это делаем на клиенте. Это означает, что у нас наконец есть возможность реализовать весь наш пользовательский интерфейс на одном языке программирования. Это не только экономит значительное количество времени, но мы теперь свободны от багов, возникающих из-за того, что какая-нибудь одна из функций реализована в двух местах. Любые обновления теперь могут быть сделаны одним человеком.

React и Redux также приносят с собой ряд интересных идей, например как то, что пользовательский интерфейс является функцией состояния приложения. Мы больше не сохраняем состояние приложения в DOM, как это было бы с jQuery, поток состояния теперь изменился в обратную сторону. Состояние может находится в хранилище, а всем компонентам нужно сделать повторную отрисовку при каждом обновлении состояния. Хотя потребуется какое-то время, чтобы разобраться в этой концепции, но после этого ваш код станет легче для понимания.

Теперь я хотел бы рассмотреть некоторые из поднятых вопросов.

Перепишите свою разметку на JSX. Обязательно замените атрибут class на className, иначе ничего не заработает.

Причина в том, что JSX представляет собой JS-представление сегмента DOM, который выводит наш компонент. Мы не можем использовать class, потому что это зарезервированное ключевое слово в JavaScript, используемое для объявления классов, появившихся в ES6. className — неплохая альтернатива, поскольку это имя свойства, которое DOM-элементы используют для обозначения атрибута класса.

Встроенный атрибут onClick, добавляемый к вашему JSX, сопоставляется с функцией для обработки щелчка мыши.

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

Одно сходство, которое React имеет с jQuery — это то, что они оба гарантируют одинаковую работоспособность событий во всех браузерах, что пытается сделать нашу жизнь немного легче.

Добавьте this.handleClick = this.handleClick.bind(this); в конструктор, чтобы вызов метода класса заработал.

Контекстное разыменование — сложная тема и может подловить даже опытных разработчиков. Один из способов обойти эту проблему в React — использовать стрелочные функции, как описано в этом ишью.

Это может быть только для меня, но React кажется сравнительно более сложным и неэлегантным.

Это другой подход. Во многих случаях он будет лучше, но не всегда. Хотя может показаться, что его использование осложняет наше приложение, но на мой взгляд он на самом деле помогает нам справляться со сложностью, которая существует в больших приложениях. Я работал над приложениями, созданными с помощью React с более чем ста тысяч строк кода и на каждом шагу React был огромной помощью и играл важную роль. Некоторые проекты было бы сложно реализовать любым другим способом.

React может быть сложным, поскольку предполагает не только смену подхода к разработке, но также требует глубокого понимания основ JavaScript. Если вас это интересует, я запускаю учебную программу по JavaScript в Лондоне, которая охватывает именно эту тему. У нас ещё осталось несколько мест в нашей сентябрьской группе, и я хотел бы помочь вам справиться с изучением React, а также со всеми сопутствующими технологиями.

Примечание переводчика: а для всех тех, кто не живёт в Лондоне, но хочет изучить React на базовом уровне, предлагаю прочитать небольшую бесплатную книгу «Путь к изучению React». Это перевод известной книги «The Road to learn React», которая переведена на четыре языка, а совсем недавно был закончен перевод на русский язык. Так что, если вы или кто-нибудь из вашего круга общения ещё не знают React, но желают его изучить, то эта книга будет отличным стартом для погружения в мир React!

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Статья на GitHub

React - это не новый jQuery was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

В этой обучающей статье я покажу вам, как тестировать компоненты Vue.

Мы собираемся писать модульные тесты и тесты снимками с помощью Jest и Vue Test Utils. Всё это без использования Webpack.

Это руководство предназначено для пользователей, знакомых с модульным тестированием. Если вы новичок в модульном тестировании, ознакомьтесь с моёй статьей про модульное тестирование Vue-компонентов для новичков.

Настройка

Я сделал простой проект для старта. Склонируйте его в свой каталог:

git clone https://github.com/eddyerburgh/vue-unit-test-starter.git

Примечание переводчика: со времени написания оригинальной статьи новая версия Vue Test Utils (всё ещё бета-версия), я сделал форк репозитория автора для использования актуальной на момент перевода версии Vue Test Utils , и если хотите использовать стартовый проект с последней версией Vue Test Utils, то можете склонировать этот репозиторий:

git clone git@github.com:lex111/jest-vue-example.git

Примечание: в любом случае в статье будет использоваться синтаксис новой на момент перевода версии Vue Test Utils (v1.0.0-beta.20)в целях придания актуальности переводимой статье.

Теперь перейдите в каталог с репозиторием и установите зависимости:

cd vue-unit-test-starter && npm install

Когда зависимости установлены, запустите сервер разработки:

npm run dev

Теперь мы можем вернуться к коду.

Единственное, что нужно обсудить — псевдонимы. Это способ использования сокращённой записи для импорта файла. Вместо длинных операторов импорта, как показано ниже:

import someModule from '../../../../../src/components/someModule'

Можно использовать сокращённую нотацию или псевдоним. Самый распространённый псевдоним — это символ @, который указывает на каталог src.

import someModule from '@/components/someModule'

Примечание: вы можете установить любой псевдоним, который захотите, но проекты vue-cli используют @ для ссылки на каталог src.

В проектах vue-cli Webpack используется для добавления этого псевдонима. Это классно, но мы не используем Webpack для выполнения наших тестов. По этой причине нужен другой способ разрешения псевдонимов.

Вот тут-то и вступает в дело Babel. Есть плагин babel-plugin-module-resolver, разрешающий псевдонимы в Babel. Вы можете увидеть его использование в файле .babelrc. Он применяется только в тестовом окружении, поскольку вы запускаете создание сборки в окружении разработки или продакшена, Webpack разрешает данный псевдоним.

Взгляните на следующий файл:

Итак, мы получили общее представление проекта, пришло время добавить Jest.

Jest

Jest — фреймворк для тестирования. Это один из самых быстрых фреймворков для тестирования однофайловых Vue-компонентов (SFC).

Помимо выполнение тестов, Jest поставляется с другими возможностями из коробки, такими как подставные (mock) объекты, покрытие кода и тестирование снимками.

Первое, что нужно сделать, это установить Jest:

npm install --save-dev jest

Для тестирования однофайловых компонентов, вам нужно скомпилировать их в JavaScript до выполнения тестов. Если вы попытаетесь запустить нескомпилированный однофайловый компонент, вы получите синтаксическую ошибку.

Jest не компилирует файлы с расширением .vue из коробки. Вам нужно указать это для их компиляции. Это достигается путём добавления поля jest в файл package.json.

Добавьте код ниже в свой package.json.

"jest": {
    "moduleFileExtensions": [
        "js",
        "json",
        "vue"
    ],
    "transform": {
        "^.+\\.js$": "<rootDir>/node_modules/babel-jest",
        ".*\\.(vue)$": "<rootDir>/node_modules/vue-jest"
    }
}

Вы видите поле moduleFileExtensions. Это указывает Jest, чтобы он выполнял файлы с расширением .vue, а также с расширениями .js и .json.

Также есть поле transform. Оно указывает Jest, как компилировать файлы перед их выполнением. Он находит все файлы с расширением .js и компилирует их с помощью babel-jest. Все vue-файлы компилируются с использованием vue-jest.

Это пользовательские преобразования, созданные для Jest: babel-jest компилирует JavaScript, vue-jest берёт файлы с расширением .vue и компилирует их в JavaScript.

Учитывая написанное выше, необходимо установить два пакета:

npm install --save-dev babel-jest vue-jest

Хорошо, теперь нам нужно добавить тест «на дым» (smoke test), чтобы убедиться, что всё работает, как следует.

В src/components создайте каталог __tests__. Добавьте файл MessageToggle.spec.js. Таким образом полный путь к тесту будет src/components/__tests__/MessageToggle.spec.js.

Скопируйте приведённый ниже код:

Jest автоматически запускает все JS-файлы в каталоге __tests__. Он даже добавляет переменную тестового окружения, поэтому весь тестовый скрипт выполняется Jest.

В поле script вашего package.json добавьте скрипт unit:

"unit": "jest"

Теперь запустите этот скрипт:

npm run unit

Отлично, первый тест пройдён 👌.

Теперь мы напишем более сложные тесты с помощью Vue Test Utils.

Vue Test Utils

Vue Test Utils в данный момент находится в бета-версии, но прямо сейчас вы можете использовать его без особых проблем, т.к. работа над API в значительной степени завершена.

Установите его:

npm install --save-dev vue-test-utils

Теперь вы напишите аналогичный тест MessageToggle.spec.js, используя Vue Test Utils.

Скопируйте код ниже в файл src/components/__tests__/MessageToggle.spec.js.

Здесь мы можем использовать функцию shallowMount для возврата объекта-обёртки. Обёртка содержит разные вспомогательные методы, например, text, который помогает проверять утверждения компонентов. Вы можете посмотреть полный список методов обёртки здесь.

Итак, добавим более сложный тест, выполняющий действие на компоненте Messagetoggle. Скопируйте код ниже в MessageToggle.spec.js:

В этот раз мы нажимаем на кнопку (с #toggle-message) в MessageToggle и проверяем, что текст тега <p> изменился правильно.

Теперь запустите скрипт для запуска тестов:

npm run unit

Опа, тесты проходят! 🙌

Vue Test Utils абстрагирует внутренности Vue. Поэтому что вам нужно сделать — изучить API Vue Test Utils.

Теперь напишем тест для компонента List. Компонент List принимает свойства, к счастью, предоставляет способ передать свойства при монтировании компонента.

Создайте файл /src/components/__tests__/List.spec.js и вставьте код ниже:

На этот раз, как вы видите, мы используем функцию shallowMount. Это то же самое, что и mount, за исключением того, компонент отрисовывается только на один уровень. Как правило, лучше использовать shallowMount.

Теперь, когда вы написали модульные тесты, пришло время взглянуть на тестирование снимками.

Тестирование снимками

У Jest есть такая замечательная возможность, называемая тестированием снимками.

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

Давайте добавить тест снимка в Message.spec.js.

Вам нужно отрисовать компонент в строку с помощью vue-server-renderer. Возвращаемая строка не очень читабельная, поэтому добавим ещё jest-serializer-vue, чтобы придать красивый, читаемый вид вашим снимкам.

npm install --save-dev vue-server-renderer jest-serializer-vue

Также вам нужно сообщить Jest для использования сериализатора. Добавьте поле snapshotSerializers внутри поля jest в ваш файл package.json:

"snapshotSerializers": [
    "<rootDir>/node_modules/jest-serializer-vue"
]

Теперь обновите List.spec.js для добавления теста снимка:

Этот тест неглубоко монтирует компонент и отрисовывает его в строку с HTML через использование vue-server-renderer.

Теперь запустим выполнение тестов:

npm run unit

В терминале вы увидите уведомление о сохранении только что созданного снимка. Вы можете увидеть, если перейдите в файл src/components/__tests__/__snapshots__/List.spec.js.snap:

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`List.vue has same HTML structure 1`] = `
<ul>
    <li>
        list item one
    </li>
    <li>
        list item two
    </li>
</ul>
`;

Круто, это и есть снимок. 📸

Теперь, если разметка List.vue изменится, Jest предупредит вас об этом при выполнении тестов.

Выводы

Итак, теперь вы создали модульные тесты и тесты снимками, используя Jest и Vue Test Utils.

Я пропустил ряд концепций. Вы можете посмотреть на готовый репозиторий на GitHub (или посмотреть на тот же самый форк этого репозитория с использованием последней версией Vue Test Utils.), если ваш проект некорректно работает.

В Jest имеется больше возможностей для облегчения тестирования.

А у Vue Test Utils в свою очередь также есть много методов — изучите документацию.

Из-за того, что русская документация по Vue Test Utils вышла совсем недавно после больших изменений, приветствуются различные исправления опечаток и неточностей. Пожалуйста, создайте PR с обновлениями в форк оригинального репозитория на Translation Gang, так как это сообщество переводит и поддерживает документации по продуктам Vue

Модульное тестирование Vue-компонентов ещё никогда не было таким простым, так что вперёд писать тесты!

Если вы узнали что-то интересное из этой статьи, поделитесь ею и не забывайте про 👏 для того, чтобы о ней узнали другие!

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Статья на GitHub

Vue Test Utils и Jest: как писать простые модульные тесты для фронтенда was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

Очень мало людей, которые пишут Vue-компоненты, изначально собираются выложить их в открытый доступ. Большинство из нас начинают писать компоненты по принципу — у нас есть проблема, которую мы хотим решить, написав для этого компонент. Иногда мы хотим решить одну и ту же проблему в разных местах нашей кодовой базы, поэтому мы берём компонент и рефакторим его немного для того, чтобы сделать повторно используемым. Затем мы хотим использовать компонент в другом проекте и для этого переносим его в отдельный пакет. Тогда у нас возникает мысль: «А почему бы не поделиться этим компонентом с остальным миром?» и мы делаем наш компонент свободно доступным.

С одной стороны, это здорово, что означает большую и растущую доступность компонентов с открытым исходным кодом для всех, кто работает с Vue (поиск по «vue» на npmjs.com показывает более 13 000 пакетов).

С другой стороны, поскольку большинство из этих компонентов эволюционировали из конкретной ситуации, и не у всех из нас имеется опыт разработки компонентов для повторного использования в различных окружениях, многие из них не “хорошо взаимодействуют” (в оригинале “play nice” — прим. пер.) с экосистемой Vue.

Что значит “хорошо взаимодействует”? В общих чертах это означает, что он выглядит вполне естественным для разработчиков Vue, а также его легко расширить и интегрировать в любое приложение.

После изучения широкого набора различных компонентов с открытым исходным кодом, вот что я думаю о Vue-компонентах, которые хорошо взаимодействуют:

1. Реализована совместимость с директивой v-model
2. Компонент прозрачен для событий
3. Есть возможность присваивать атрибуты необходимым элементам
4. Придерживаются норм браузеров для навигации по клавиатуре
5. Отдаётся предпочтение обработчикам событий, а не колбэкам
6. Видимость стилей ограничена компонентом

Реализована совместимость с директивой v-model

Для компонентов, которые по сути являются полями формы — будь то автозаполнение полей для поиска, поля с календарём для ввода даты или что-то ещё, иначе говоря, реализуют дополнительную функциональность для одного поля, позволяющую пользователю указывать данные — одним из наиболее важных способов быть естественным для Vue является поддержка v-model.

Согласно руководству Vue по компонентам директива v-model на компонентах, в основном, работает через передачу свойства value с применением обработчика событий input.

Например, если бы мы реализовывали элемент ввода даты, который оборачивает поле ввода, то мы инициализировали бы его с использованием свойства value, а при выборе даты вызывали событие input, и в итоге код выглядел бы следующим образом:

import datepicker from 'my-magic-datepicker';

export default {
  props: ['value'],
  mounted() {
    datepicker(this.$el, {
      date: this.value,
      onDateSelected: (date) => {
        this.$emit('input', date);
      },
    });
  }
}

Компонент прозрачен для событий

Для реализации поддержки директивы v-model необходимо реализовать событие input. Но как насчёт других событий, таких как события нажатий с мыши и клавиатуры и т.д.? В то время как нативные события всплывают в HTML (DOM), обработчики событий во Vue по умолчанию не делают это.

Например, если я сделаю что-то подобное, это не сработает:

<my-textarea-wrapper @focus="showFocus">

До тех пор, пока мы не напишем код в компоненте-обёртке, который на самом деле генерирует событие focus, обработчик события showFocus никогда не будет вызван. Однако Vue предоставляет нам способ для доступа к применяемым компоненту обработчикам событий, поэтому мы можем присвоить в нужным месте объект $listeners.

<div class="my-textarea-wrapper">
  <textarea v-on="$listeners"></textarea>
</div>

Теперь события, которые происходят на текстовом многострочном поле, будут всплывать как обычно.

Есть возможность присваивать атрибуты необходимым элементам

Как насчёт таких атрибутов как rows для полей с текстовыми областями или title для добавления простой подсказки к любому атрибуту через соответствующий HTML-атрибут.

По умолчанию Vue принимает атрибуты, применяемые к атрибуту, и помещает их в корневой элемент этого компонента. Это не всегда то, что вам нужно. Однако, если мы снова посмотрим на обёртку над тегом textarea, то в этом случае имело смысл применять атрибуты к самому элементу, а не оборачивающему тегу div.

Чтобы сделать это, мы указываем компоненту не применять атрибуты по умолчанию, а вместо этого назначать их непосредственно, используя объект $attrs. В нашем JavaScript-коде:

export default {
  inheritAttrs: false,
}

А затем в нашем шаблоне:

<div class="my-textarea-wrapper">
  <textarea v-bind="$attrs"></textarea>
</div>

Придерживаются норм браузеров для навигации по клавиатуре

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

В основе этого лежит соответствие стандартам браузера: клавиша табуляция должна позволять выбирать поля формы. Клавиша ввода обычно используется для нажатия на кнопку или перехода по ссылке.

Полный список навигаций по клавиатуре для стандартных компонентов можно найти на сайте W3C. Следуя этим рекомендациям, ваш компонент можно будет использовать во всех приложениях, а не только в тех, которым нужна доступность.

Отдаётся предпочтение обработчикам событий, а не колбэкам

Когда дело до взаимодействия данными и пользовательскими действиями от вашего компонента к его родителям, то есть два распространённых варианта: колбэки во входных параметрах (они же свойства) и события. Поскольку пользовательские события не всплывают как нативные браузерные события, они функционально одинаковы, но для возможности повторного использования я почти всегда рекомендую использовать события вместо колбэков. Почему?

В одном выпуске подкаста Fullstack Radio Крис Фриц, один из разработчиков основной команды Vue, привёл следующие причины:

1. Использование событий делают компонент более прозрачным в плане того, что должны о нём знать родительские компоненты. Он создаёт чёткое разделение между тем, что получено от родительских компонентов и тем, что отправлено им.
2. Вы можете использовать выражения непосредственно в обработчиках событий, позволяя держать их очень компактными для обычных случаев.
3. Это больше соответствует Vue — примеры и документация Vue обычно используют события для связи взаимодействия компонента с родительскими компонентами.

К счастью, если вы используете подход «колбэки в свойствах» (callbacks-in-props), довольно просто изменить компонент для генерации событий вместо этого. Компонент, использующий колбэки, может быть таким:

// файл my-custom-component.vue
export default {
  props: ['onActionHappened', ...]
  methods() {
    handleAction() {
      // остальной код...
      if (typeof this.onActionHappened === 'function') {
        this.onActionHappened(data);
      }
    }
  }
}

Далее при его использование может выглядит так:

<my-custom-component :onActionHappened="actionHandler" />

Переход на новый подход, основанный на событиях, будет выполнен следующим образом:

// файл my-custom-component.vue
export default {
  methods() {
    handleAction() {
      // остальной код...
      this.$emit('action-happened', data);
    }
  }
}

И использование компонента изменится на:

<my-custom-component @action-happened="actionHandler" />

Видимость стилей ограничена компонентом

Однофайловые компоненты позволяют встраивать стили непосредственно в компоненты, и особенно в сочетании с ограничением области видимости CSS-стилей через атрибут scoped даёт нам отличный способ использовать полностью упакованные, стилизованные компоненты таким образом, чтобы они не влияли на другие части приложения.

Благодаря такой возможности у вас может возникнуть соблазн поместить все стили в компонент и отправлять в открытый доступ такой полностью стилизованный компонент. Здесь следующая проблема: не все стили приложения одинаковые, и те стили, благодаря которым ваше приложение выглядит хорошо, в чьём-то другом приложении будут выглядеть совсем наоборот.

Для предотвращения этого я рекомендую сделать так, чтобы все структурные CSS-стили (цвета, рамки, тени и т.д.) были либо исключены из компонента, либо должны быть доступны для отключения в нём. Как вариант, рассмотрите возможность использования настраиваемого SCSS-файла (partial), который позволит пользователям вашего компонента стилизовать его так, как это будет необходимо.

Недостаток использования внешнего SCSS-файла заключается в том, что вашим пользователям потребуется подключать этот файл в свою систему сборки для компиляции стилей в CSS, иначе им будет показан компонент без стилей. Для получения лучшего из обоих миров, вы можете ограничить область действия стилей в компонента служебным классом, который будет передаваться через входной параметр (свойство компонента), для отключения стилей по умолчанию и удовлетворения потребностей тех пользователей, которые хотят иметь собственное оформление компонента. Если вы создаёте SCSS-стили в виде миксина, то вы могли бы использовать одинаковые SCSS-стили для пользователей, которым требуется большая гибкость для стилизации компонента.

<template>
  <div :class="isStyledClass">
    <!-- мой компонент -->
  </div>
</template>

Далее в вашем JavaScript-коде компонента:

export default {
  props: {
    disableStyles: {
      type: Boolean,
      default: false
    }
  },
  computed: {
    isStyledClass() {
      if (!this.disableStyles) {
        return 'is-styled';
      }
  },
}

Тогда вы сможете использовать так:

@import 'my-component-styles';

.is-styled {
  @include my-component-styles();
}

Данное решение позволит стилизовать компонент из коробки, но даёт возможность пользователям определять собственную стилизацию компонента с помощью установки свойства disableStyles в значение true без всякого переопределения стилей с более высокой специфичностью, либо использовать ваш миксин с их стилями, или вообще полностью с нуля стилизовать компонент.

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Статья на GitHub

Как писать Vue-компоненты, которые хорошо взаимодействуют was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

Рассмотрим ECMAScript как язык, на котором вы разговариваете, например, английский. Тогда JavaScript будет диалектом, скажем, британского английского. Диалект — это сам язык, но основанный на принципах языка, из которого он произошёл. Итак, ECMAScript — это книга рецептов для приготовления/написания JavaScript, и только от шеф-повара/разработчика зависит, следовать его ингредиентам/правилам или нет.

Как правило, последователи (adopters) JavaScript соблюдают все спецификации, написанные в языке (иначе разработчики сойдут с ума), и отправляют новую версию движка JavaScript очень поздно, пока до конца не убедятся, что всё работает как надо. TC39 или технический комитет 39 (Technical Committee 39) в ассоциации ECMA International отвечает за поддержку спецификаций языка ECMAScript. Члены этой команды являются частью ECMA International, разработчиками браузеров и представителями компаний, заинтересованных вебом в целом.

Поскольку ECMAScript — это открытый стандарт, любой может предложить новые идеи или возможности и работать над ними. Следовательно, предложение новой функциональной возможности проходит через 4 основные этапа, и TC-39 участвует в этом процессе, пока предложение не будет готово к внедрению.

• Нулевой этап (stage 0) — кандидат на предложение (strawman)
  Представить новую возможность (предложение) в комитет TC-39. Как правило представляется членом TC39 или помощником (contributor) TC39.
• Первый этап (stage 1)— предложение (proposal)
  Определить варианты использования предложения, зависимости, задачи, демонстрации, полифилы и т.д. Куратор (член TC39) будет отвечать за это предложение.
• Второй этап (stage 2)— черновик (draft)
  Это первоначальная версия возможности, которая в конечном счёте будет добавлена. Следовательно, должны быть представлены описание и синтаксис. Транспилер, такой как Babel, должен поддерживать и продемонстрировать реализацию.
• Третий этап (stage 3) — кандидат (candidate)
  Предложение почти готово и некоторые изменения могут быть сделаны в ответ на критические проблемы, поднятые последователями и комитетом TC39.
• Четвертый этап (stage 4) — готов (finished)
  Предложение готово для включения в стандарт.

В настоящее время (июнь 2018) декораторы находятся на втором этапе, и у нас есть Babel-плагин для транспиляции декораторов babel-plugin-transform-decorators-legacy. Предложения, находящиеся на втором этапе не рекомендуются для использования в продакшене, поскольку синтаксис новой возможности подвержен изменениям. В любом случае, декораторы прекрасны и очень полезны для ускорения процесса разработки.

С этого момента мы работаем с экспериментальным JavaScript, поэтому ваша версия Node.js может не поддерживать данную возможность. Поэтому нам нужен транспилятор Babel или TypeScript. Используйте плагин js-plugin-starter для настройки очень простого проекта, в котором я добавил поддержку декораторов, которые мы рассмотрим в статье.

Для понимания декораторов нужно сначала разобраться, что такое дескриптор свойства (property descriptor) объекта в JavaScript. Дескриптор свойства представляет собой набор правил для свойства объекта, как например, является ли свойство доступным для записи (writable) или перечислимым (enumerable). Когда мы создаём простой объект и добавляем некоторые свойства, у каждого из свойств есть дескриптор свойства по умолчанию.

var myObj = {
    myPropOne: 1,
    myPropTwo: 2
};

myObj — простой JavaScript-объект, который выглядит следующим образом в консоли

Теперь, если присвоим новое значение для свойства, как показано ниже, операция завершится успешно и мы получим изменённое значение.

myObj.myPropOne = 10;
console.log(myObj.myPropOne); //==> 10

Для получения дескриптора свойства, нам нужно использовать метод Object.getOwnPropertyDescriptor(obj, propName). Own означает вернуть дескриптор свойства propName, только если оно принадлежит объекту obj, а не его цепочке прототипов.

const descriptor = Object.getOwnPropertyDescriptor(
    myObj,
    'myPropOne'
);

console.log(descriptor);

Метод Object.getOwnPropertyDescriptor возвращает объект с ключами, описывающими разрешения и текущее состояние свойства. value — текущее значение свойства, writable — может ли пользователь назначить новое значение для свойства, enumerable — будет ли это свойство отображаться при перечислениях, например, при итерациях цикла for in или for of, либо в Object.keys и т.д., configurable — есть ли у пользователя разрешение изменять дескриптор свойства и может ли он изменять значение на writable или enumerable. В дескрипторе свойств есть ключи get и set — промежуточные функции для возврата или обновления значений, но эти ключи необязательные.

Для создания нового свойства объекта или обновления существующего свойства с пользовательским дескриптором, мы можем воспользоваться Object.defineProperty. Давайте изменим существующее свойство myPropOne с writable на false, что запретит изменения в myObj.myPropOne.

'use strict';

let myObj = {
    myPropOne: 1,
    myPropTwo: 2
};

// изменяем дескриптор свойства
Object.defineProperty(myObj, 'myPropOne', {
    writable: false
});

// распечатываем дескриптор свойства
let descriptor = Object.getOwnPropertyDescriptor(
    myObj, 'myPropOne'
);
console.log(descriptor);

// устанавливаем новое значение
myObj.myPropOne = 2;

Как видно из вышеприведённой ошибки, наше свойство myPropOne недоступно для записи, поэтому, если пользователь попытается присвоить ему новое значение, будет выброшена ошибка.

Если Object.defineProperty обновляет существующий дескриптор свойства, тогда исходный дескриптор будет переопределен новыми изменениями. Object.defineProperty возвращает исходный объект myObj после изменений.

Давайте посмотрим, что произойдёт, если мы установим ключ дескриптора enumerable в значение false.

let myObj = {
    myPropOne: 1,
    myPropTwo: 2
};

// изменяем дескриптор свойства
Object.defineProperty(myObj, 'myPropOne', {
    enumerable: false
});

// распечатываем дескриптор свойства
let descriptor = Object.getOwnPropertyDescriptor(
    myObj, 'myPropOne'
);
console.log(descriptor);

// распечатываем ключи
console.log(Object.keys(myObj));

Как видно из приведённого выше результата в консоли, мы не видим свойство myPropOne при вызове Object.keys.

При определении нового свойства с использованием Object.defineProperty и передадим ему пустой дескриптор {}, будет задан дескриптор по умолчанию, который выглядит так:

Теперь давайте определим новое свойство с пользовательским дескриптором, где для ключа дескриптора configurable установлено значение false. Мы сохраним writable в значение false, а enumerable в значение true с value, установленным в 3.

let myObj = {
    myPropOne: 1,
    myPropTwo: 2
};

// изменяем дескриптор свойства
Object.defineProperty(myObj, 'myPropThree', {
    value: 3,
    writable: false,
    configurable: false,
    enumerable: true
});

// распечатываем дескриптор свойства
let descriptor = Object.getOwnPropertyDescriptor(
    myObj, 'myPropThree'
);
console.log(descriptor);

// изменяем дескриптор свойства
Object.defineProperty(myObj, 'myPropThree', {
    writable: true
});

Установив дескриптор ключа configurable в значение false, мы потеряли возможность изменять дескриптор нашего свойства myPropThree. Это очень полезно, если вы не хотите, чтобы ваши пользователи манипулировали рекомендуемым поведением объекта.

get (геттер) и set (сеттер) в свойстве также можно установить в дескрипторе свойства. Но когда вы определяете геттер, придётся кое-чем пожертвовать. У вас нет начального значения или ключа value в дескрипторе вообще, потому что геттер вернёт значение этого свойства. Вы также не можете использовать ключ writable в дескрипторе, потому что ваши записи выполняются через сеттер, и вы можете предотвратить запись там. Взгляните на документацию MDN по геттеру и сеттеру, или прочитайте эту статью, если вам не нужны подробные объяснения.

Вы можете и/или обновлять сразу несколько свойств, используя Object.defineProperties, принимающий два аргумента. Первый аргумент — целевой объект, свойства которого должны быть добавлены/изменены, а второй аргумент — это объект с key в качестве имени свойства и value как дескриптор свойства. Эта функция возвращает целевой объект.

У функции Object.create следующий синтаксис:

let obj = Object.create(prototype, {property: descriptor, ... })

Здесь prototype — это объект, который будет прототипом obj. Если prototype равен null, тогда у obj не будет прототипа. Когда вы определяете пустой или непустой объект с синтаксисом var obj= {} по умолчанию obj.__proto__ будет указывать на Object.prototype, следовательно, obj имеет прототип класса Object.

Это похоже на использование Object.create вместе с Object.prototype в качестве первого аргумента (прототип создаваемого объекта).

'use strict';

let obj = Object.create(Object.prototype, {
    a: { value: 1, writable: false },
    b: { value: 2, writable: true }
});

console.log(obj.__proto__);
console.log(`obj.hasOwnProperty('a') => ${obj.hasOwnProperty('a')}`);

Но когда мы устанавливаем prototype в значение null, мы получаем ошибку, показанную ниже.

'use strict';

let obj = Object.create(null, {
    a: { value: 1, writable: false },
    b: { value: 2, writable: true }
});

console.log(obj.__proto__);
console.log(`obj.hasOwnProperty('a') => ${obj.hasOwnProperty('a')}`);

✱ Декоратор метода класса

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

Декоратор — это функция JavaScript (рекомендуется чистая функция), которая используется для изменения свойств/методов класса или самого класса. Когда вы добавляете синтаксис @decoratorFunction в начало свойства класса или метода, либо самого класса, decoratorFunction вызывается с несколькими аргументами, которые мы можем использовать для изменения класса или свойств класса.

Давайте создадим простую функцию декоратора readonly. Но до этого давайте создадим класс User с методом getFullName, который возвращает полное имя пользователя, путём объединения firstName и lastName.

class User {
    constructor(firstname, lastName) {
        this.firstname = firstname;
        this.lastName = lastName;
    }

    getFullName() {
        return `${this.firstname} ${this.lastName}`;
    }
}

// создаём экземпляр
const user = new User('John', 'Doe');
console.log(user.getFullName());

Код выше выведет John Doe на консоль. Но есть огромная проблема, поскольку кто-то может изменить метод getFullName.

User.prototype.getFullName = function() {
    return 'ВЗЛОМАНО!';
}

При это мы получим следующий результат.

ВЗЛОМАНО!

Чтобы избежать общедоступного доступа для переопределения любого из наших методов, нам нужно изменить дескриптор свойства метода getFullName, который находится в объекте User.prototype.

Object.defineProperty(User.prototype, 'getFullName', {
    writable: false
});

Теперь, если пользователь попытается переопределить метод getFullName, он получит ошибку.

Но если у нас несколько методов в классе User, делать вручную это не так здорово. Поэтому в таком случае на помощь приходит декораторы. Мы можем добиться того же, добавив синтаксис @readonly перед методом getFullName, как показано ниже.

function readonly(target, property, descriptor) {
    descriptor.writable = false;
    return descriptor;
}

class User {
    constructor(firstname, lastName) {
        this.firstname = firstname;
        this.lastName = lastName;
    }

    @readonly
    getFullName() {
        return `${this.firstname} ${this.lastName}`;
    }
}

User.prototype.getFullName = function() {
    return 'ВЗЛОМАНО!';
}

Посмотрите на метод readonly. Он принимает три аргумента. property — это имя свойства/метода в объекте target (который идентичен User.prototype), а descriptor — дескриптор переданного свойства. Внутри функции декоратора мы должны возвратить descriptor. Этот descriptor заменит существующий дескриптор свойства для этого свойства.

Существует ещё одна версия синтаксиса декоратора, похожая на @decoratorWrapperFunction(...customArgs). Но с этим синтаксисом decoratorWrapperFunction должен вернуть decoratorFunction, который аналогичен в используемом ранее примере.

function log(logMessage) {
    // возвращаем функцию декоратора
    return function (target, property, descriptor) {
        // сохраняем исходное значение, которое является методом (функцией)
        const originalMethod = descriptor.value;

        // заменяем реализацию метода
        descriptor.value = function(...args) {
            console.log('[LOG]', logMessage);

            // вызов исходного метода
            // `this` указываем на экземпляр
            return originalMethod.call(this, ...args);
        };

        return descriptor;
    }
}

class User {
    constructor(firstname, lastName) {
        this.firstname = firstname;
        this.lastName = lastName;
    }

    @log('calling getFullName method on User class')
    getFullName() {
        return `${this.firstname} ${this.lastName}`;
    }
}

var user = new User('John', 'Doe');
console.log(user.getFullName());

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

@log('calling getFullName method on User class')
static getVersion() {
    return 'v1.0.0';
}

console.log(User.getVersion());

✱ Декоратор полей экземпляра класса

До сих пор мы видели изменение дескриптора свойства с помощью синтаксиса @decorator или @decorator(..args), но как насчёт общедоступных/закрытых свойств (полей экземпляра класса)?

В отличие от typescript или java у JavaScript-классов нет полей экземпляра класса или свойств класса. Это связано с тем, что всё, что определено в class и вне constructor, должно принадлежать прототипу. Но есть новое предложение для включения полей экземпляра класса с модификаторами доступа public и private, который сейчас находится на третьем этапе, и для него есть соответствующий Babel-плагин.

Давайте определим простой класс User, но на этот раз нам не нужно устанавливать значения по умолчанию для firstName и lastName.

class User {
    firstName = 'default_first_name';
    lastName = 'default_last_name';

    constructor(firstName, lastName) {
        if (firstName) {
            this.firstName = firstName;
        }
        if (lastName) {
            this.lastName = lastName;
        }
    }

    getFullName() {
        return `${this.firstname} ${this.lastName}`;
    }
}

const defaultUser = new User();
console.log('[defaultUser] ==> ', defaultUser);
console.log('[defaultUser.getFullName] ==> ', defaultUser.getFullName());

const user = new User( 'John', 'Doe' );
console.log('[user] ==> ', user);
console.log('[user.getFullName] ==> ', user.getFullName());

Теперь, если проверите prototype класса User, вы не увидите свойства firstName и lastName.

Поля экземпляров класса очень полезная и важная часть объектно-ориентированного программирования (ООП). Хорошо, что есть предложение для этого, но эта история ещё далека от завершения.

В отличие от методов класса, которые находятся в прототипе класса, поля экземпляра класса существуют в объекте/экземпляра. Поскольку поле экземпляра класса не является ни частью класса, ни его прототипом, очень сложно изменить его дескриптор. Babel даёт нам функцию initializer в дескрипторе свойства поля экземпляра класса вместо value. Почему используется функция initializer вместо ключа value — эта тема обсуждается, и поскольку декораторы находятся на второй стадии, окончательный черновик ещё не опубликован, чтобы объяснить причины этого, но вы можете последовать ответу на Stack Overflow, чтобы понять предысторию.

С учётом вышесказанного давайте изменим предыдущей пример и создадим простой декоратор @upperCase, который изменит регистр значение поля по умолчанию экземпляра класса.

function upperCase( target, name, descriptor ) {
    const initValue = descriptor.initializer();

    descriptor.initializer = function() {
        return initValue.toUpperCase();
    }

    return descriptor;
}
class User {
    @upperCase
    firstName = 'default_first_name';

    lastName = 'default_last_name';

    constructor(firstName, lastName) {
        if (firstName) {
            this.firstName = firstName;
        }
        if (lastName) {
            this.lastName = lastName;
        }
    }

    getFullName() {
        return `${this.firstname} ${this.lastName}`;
    }
}
console.log(new User());

Мы также можем использовать функцию декоратора с параметрами, чтобы сделать его более настраиваемым.

function toCase(CASE = 'lower') {
    return function (target, name, descriptor) {
        const initValue = descriptor.initializer();

        descriptor.initializer = function() {
            return
                (CASE === 'lower') ?
                initValue.toLowerCase() :
                initValue.toUpperCase();
        }

        return descriptor;
    }
}
class User {
    @toCase('upper')
    firstName = 'default_first_name';

    lastName = 'default_last_name';

    constructor(firstName, lastName) {
        if (firstName) {
            this.firstName = firstName;
        }
        if (lastName) {
            this.lastName = lastName;
        }
    }

    getFullName() {
        return `${this.firstname} ${this.lastName}`;
    }
}

console.log(new User());

Функция descriptor.initializer используется внутри Babel для создания ключа value дескриптора свойства в свойстве объекта. Эта функция возвращает начальное значение, присвоенное полю экземпляра класса. Внутри декоратора нам нужно вернуть ещё одну функцию initializer, которая вернет окончательное значение.

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

Декоратор класса

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

Декораторы класса немного отличаются от декораторов, которые мы видели ранее. Раньше мы использовали дескриптор свойства для изменения поведения свойства или метода, но в случае с декоратором класса нам нужно вернуть функцию конструктора.

Давайте разберёмся сначала, что такое функция конструктора. JavaScript-класс на самом деле это не что иное, как функция, используемая для добавления методов прототипа и определения некоторых значений для полей.

function User(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
}

User.prototype.getFullName = function() {
    return `${this.firstname} ${this.lastName}`
}

const user = new User('John', 'Doe');

console.log(user);
console.log(user.__proto__);
console.log(user.getFullName());

Вот большая статья для понимания this в JavaScript.

Итак, когда мы вызываем new User, вызывается функция User с аргументами, которые мы передали, и взамен мы получаем объект. Получается, User — функция-конструктор. Кстати говоря, каждая функция в JavaScript является функцией-конструктором, поскольку, если вы посмотрите на function.prototype, вы получите свойство constructor. Пока мы используем ключевое слово new с функцией, мы должны ожидать возврата объекта.

Если вы вернете корректный объект JavaScript из функции конструктора, то это значение будет использоваться вместо создания нового объекта, используя присваивания через this. Это сломает цепочку прототипов, потому что у возвращённого объекта не будет методов прототипа функции конструктора.

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

Предположим, у меня есть простой класс User, как показано ниже.

class User {
    constructor(firstName, lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

Сейчас у нашего класса User нет никаких методов. Как говорилось ранее, декоратор класса должен вернуть функцию-конструктор.

function withLoginStatus(UserRef) {
    return function(firstName, lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.loggedIn = false;
    }
}

@withLoginStatus
class User {
    constructor(firstName, lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

let user = new User('John', 'Doe');
console.log(user);

Функция декоратора класса получает целевой класс UserRef, который в приведённом выше примере является User (на котором применяется декоратора) и должен возвращать функцию-конструктор. Это открывает двери для бесконечных возможностей, которые можно сделать с декоратором. Следовательно, декораторы класса более популярны, чем декораторы методов/свойств.

Но приведённый выше пример слишком простой, и мы не хотим создавать новый конструктор, когда как наш класс User может иметь массу свойств и прототипов. Хорошая новость заключается в том, что у нас есть ссылка на класс внутри функции декоратора, то есть UserRef. Мы можем вернуть новый класс из функции конструктора, который расширяет User класс (точнее класс UserRef). Поскольку класс тоже функция-конструктор, то это сработает.

function withLoginStatus( UserRef ) {
    return class extends UserRef {
        constructor(...args ) {
            super(...args);
            this.isLoggedIn = false;
        }

        setLoggedIn() {
            this.isLoggedIn = true;
        }
    }
}

@withLoginStatus
class User {
    constructor(firstName, lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

let user = new User('John', 'Doe');
console.log('Before ===> ', user);

// установить, что пользователь вошёл
user.setLoggedIn();
console.log('After ===> ', user);

Вы можете объединить несколько декораторов вместе, разместив их друг под другом. Порядок выполнения их будет таким же, как порядок добавления.

Декораторы — это красивый способ быстрее достичь цели. Подождите некоторое время, пока они не будут добавлены в спецификации ECMAScript.

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook. Статья на GitHub

Минимальное руководство по декораторам ECMAScript was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

Перевод статьи Harshal Patil: Vue.js — Considerations and Tricks.

Vue.js — отличный инструмент. Однако, когда вы начинаете создавать крупномасштабные приложения на JavaScript, вы сталкиваетесь с границами Vue.js. Эти границы на самом деле не ограничивают фреймворк, скорее это важные решения проектирования, принимаемые периодически командой Vue.js.

В отличие от React или Angular, Vue.js удовлетворяет потребности разного уровня разработчиков. Это дружелюбный, простой в использовании для начинающих и не менее гибкий для экспертов. Он не пытается уйти от DOM. Вместо этого он хорошо работает с ним.

С учётом вышесказанного, эта статья будет больше похожа на каталог из отличных дискуссий, вопросов и трюков, которые мне попались на пути к просветлению Vue.js.

Опять же, приведённые обсуждения актуальны на день написания статьи (18 мая 2018 года). При обновлении фреймворка, браузера или JS API, они могут потерять достоверность и стать непонятными.

1. Почему Vue.js не использует ES-классы из коробки для компонентов?

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

Создатель Vue.js, Эван Ю, отлично ответил на этот вопрос в комментарии на GitHub:

Use standard JS classes instead of custom syntax? · Issue #2371 · vuejs/vue

Вот три главные причины, по которым не используются классы для объявления компонентов:

1. ES-классы недостаточно хороши для удовлетворения требований текущего API Vue.js. Классы в ES не полностью реализованы и их часто критикуют как шаг в неверном направлении. Классы с приватными полями и декораторами, после их стабилизации (достижения stage 3, как минимум), возможно, помогут.
2. ES-классы отлично подходят только тем, кто знаком с языками программирования с поддержкой ООП. Это просто исключает значительную часть веб-сообщества, которая не использует сложные инструменты для сборки проектов или транспилеры.
3. Создание отличной иерархии компонентов пользовательского интерфейса (UI) — это отличная композиция компонентов. Речь идёт не о большой иерархии наследования. К сожалению, классы в ES лучше подходят для последнего.

2. Как я могу создать собственный абстрактный компонент?

Если создания крупномасштабных приложений недостаточно, у вас может появится сумасшедшая идея реализации абстрактного компонента, например <transition> или <router-view>. Определённо была дискуссия по этому поводу, но в реальности она ничем не кончилась.

Any plan for docs of abstract components? · Issue #720 · vuejs/vuejs.org

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

Написание абстрактных компонентов во Vue.js

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

How do I extend another VueJS component in a single-file component? (ES6 vue-loader)

3. Мне не очень нравится подход с однофайловым компонентом. Я больше привык к разделению HTML, CSS и JavaScript

Никто не мешает вам сделать подобное. Если вы философ старой школы «важности разделения», который любит буквально всё разделять на отдельные файлы или ненавидеть странное поведение с файлами .vue, то, безусловно, это возможно. Всё, что вам нужно сделать:

<!-- https://ru.vuejs.org/v2/guide/single-file-components.html -->

<!-- my-component.vue -->
<template src="./my-component.html"></template>
<script src="./my-component.js"></script>
<style src="./my-component.css"></style>

Однако сразу возникает следующий вопрос: мне всегда нужно 4 файла (vue + html + js + css) для моего компонента. Могу ли я избавиться каким-то образом от файлов .vue? Ответ - определённо, да, у вас есть такая возможность, используя vue-template-loader.

ktsn/vue-template-loader

Мои коллеги написали по поводу этого отличный пост:

Использование vue-template-loader с Vue.js для компиляции шаблонов HTML

4. Функциональные компоненты

Благодаря React.js функциональные компоненты стали сумасшествием, пусть и с благими намерениями: они быстрые, без состояния и легко тестируются. Тем не менее, у них есть подводные камни.

4.1 Почему я не могу использовать класс, основанный на декораторе @Component для функциональных компонентов?

Снова возвращаясь к классам, следует отметить, что классы представляют собой структуры данных для хранения локального состояния. Если функциональные компоненты не имеют состояния, то нет никакого смысла в использовании декоратора @Component.

Соответствующее обсуждение имеется по адресу:

How to create functional component in @Component? · Issue #120 · vuejs/vue-class-component

4.2 Внешние классы не применяются к функциональным компонентам

Функциональные компоненты не имеют привязки к классу и стилю, как обычные компоненты. Нужно вручную применять эти привязки внутри функции отрисовки.

• DOM class attribute not rendered properly with functional components · Issue #1014 · vuejs/vue-loader
• class attribute ignored on functional components · Issue #7554 · vuejs/vue

4.3 Функциональные компоненты всегда повторно отрисовываются?

TLDR: будьте осторожны при использовании компонентов с состоянием внутри функциональных компонентов

Functional components are re-rendered when props are unchanged. · Issue #4037 · vuejs/vue

Функциональные компоненты — нетерпеливы, что означает, что функция отрисовки вызывается напрямую. Это также означает, что вы должны:

Избегать использования компонента с состоянием непосредственно внутри в функции отрисовки, потому что это создаст различное определение компонента при каждом вызове функции отрисовки.

Функциональный компонент лучше использовать, если они являются листовыми компонентами (leaf components).

4.4 Как сгенерировать событие из функционального компонента?

Генерация события из функционального компонента не очевидна. К сожалению, об этом не написано в документации. Метод $emit недоступен в функциональном компоненте. Следующий вопрос на Stack Overflow может помочь.

How to emit an event from Vue.js Functional component?

5. Прозрачные компоненты-обёртки

Прозрачный компонент-обёртка оборачивает некоторую структуру DOM и всё ещё использует события внутри этой структуры вместо корневого элемента DOM. Например,

<!-- Обёртка компонента для поля ввода -->
<template>
    <div class="wrapper-comp">
        <label>Моя метка</label>
        <input @focus="$emit('focus')" type="text"/>
    </div>
</template>

В коде выше нас в действительности интересует тег input, а не корневой элемент div, поскольку он добавлен в основном для стилизации и косметической цели. Пользователя компонента могут интересовать несколько событий поля ввода, такие как blur, focus, click, hover и т.д. Это означает, что мы должны повторно генерировать каждое событие. Наш компонент будет выглядеть так.

<!-- Обёртка компонента для поля ввода -->
<template>
    <div class="wrapper-comp">
        <label>Моя метка</label>
        <input type="text"
            @focus="$emit('focus')"
            @click="$emit('click')"
            @blur="$emit('blur')"
            @hover="$emit('hover')"
        />
    </div>
</template>

Этот код противоречит принципу DRY (не повторяй себя) и выглядит грязным. Простое решение состоит в том, чтобы просто повторно связать ваши слушатели событий с требуемыми DOM-элементам, используя свойство vm.$listeners.

<!-- Обратите внимание на использование $listeners -->
<template>
    <div class="wrapper-comp">
        <label>Моя метка</label>
        <input v-on="$listeners" type="text"/>
    </div>
</template>
<!-- Использование: событие @focus связывается ко внутреннему элементу ввода -->
<custom-input @focus="onFocus"></custom-input>

6. Почему невозможно использовать v-on или генерировать события из слота

Я часто видел, как разработчики пытались генерировать событие из слота или прослушивать событие в слоте. Это просто невозможно.

Компонент slot предоставляется посредством вызова/родительским компонентом. Это означает, что все события должны связываться с вызывающим компонентом. Попытка прослушать эти изменения означает, что ваш родительский и дочерний компоненты тесно связаны, и есть ещё один способ сделать это, который красиво объяснил Эван Ю:

• Is it possible to emit event from component inside slot · Issue #4332 · vuejs/vue
• Suggestion: v-on on slots · Issue #4781 · vuejs/vue

7. Слот в слоте (читай: внук слота)

В какой-то момент вы столкнетесь с таким сценарием. Представьте, что у вас есть компонент, например, A, который принимает несколько слотов. Следуя принципам композиции, вы создаёте другой компонент B, использующий компонент A. Теперь вы компонент B и используете его в компоненте C.

Вопрос: как передать слот из компонента C в компонент A?

Ответ на этот вопрос зависит от того, что вы используете? Если вы используете функцию отрисовки, то это довольно тривиально. Функция отрисовки B будет такой:

// Функция render для компонента B
function render(h) {
    return h('component-a', {
        // Передача слотов, так как они относятся к компоненту A
        scopedSlot: this.$scopedSlots
    }
}

Однако, если используете шаблон как функцию отрисовки, то вам не повезло. К счастью, в этом вопросе есть прогресс, и, возможно, есть решение для такого случая.

feat(core): support passing down scopedSlots with v-bind by yyx990803 · Pull Request #7765 · vuejs/vue

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

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Статья на GitHub

Vue.js  —  соображения и трюки was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

Большинство людей, знакомых с Angular 2+, знают, что для компиляции HTML-шаблонов просто нужно добавить URL-адрес шаблона в TypeScript-файл компонента и дело с концом. В случае Vue рекомендуется использовать теги <template> для сборки разметки шаблона в подавляющем большинстве случаев.

Мы можем использовать vue-template-loader, если хотим использовать Vue со способом сборки шаблонов, как в Angular. Поскольку vue-template-loader поддерживает vue-class-component, мы можем использовать декораторы для стилевых классов компонентов (class-styled components).

vue-template-loader компилирует HTML в отдельные функции отрисовки в соответствующих TypeScript- или JavaScript-файлах.

Установка

Нам понадобится обычный проект Vue.js вместе с зависимостями webpack.

Установите vue-template-loader, используя yarn или npm, например так:

# yarn
$ yarn add vue-template-loader

# npm
$ npm install vue-template-loader

Конфигурация webpack для JavaScript

Теперь мы можем интегрировать vue-template-loader с использованием webpack.

Добавьте vue-template-loader в качестве правила в вашем конфигурационном файле webpack.config.js:

module.exports = {
  module: {
    rules: [
        {
          test: /\.html$/,
          loader: 'vue-template-loader',
          // Мы не хотим передавать файл `src/index.html` этому загрузчику.
          exclude: /index.html/,
        }
    ]
  }
}

Отрисовку ресурсов, используемых в HTML-шаблоне, связанных с обработкой атрибута src в тегах, можно указать с помощью опций:

module.exports = {
  module: {
    rules: [
      {
        test: /\.html$/,
        loader: 'vue-template-loader',

        // Мы не хотим передавать файл `src/index.html` этому загрузчику.
        exclude: /index.html/,
        options: {
          transformToRequire: {
            img: 'src'
          }
        }
      }
    ]
  }
}

Обратите внимание, что для работы вышеуказанных опций также необходимо добавление загрузчика для обработки файлов изображений (см. file-loader).

Конфигурация для TypeScript

Если мы хотим использовать vue-template-loader с TypeScript, нам нужны зависимости tsloader и typescript, установленные в проекте вместе с webpack.

vue-template-loader используется аналогичным образом для конфигурации webpack как для JavaScript, так и для TypeScript.

Единственное дополнение будет в каталоге typings нашего проекта. Нам нужно добавить шим в typings, чтобы TypeScript понимал файлы .vue:

// Для работы/импорта файлов *.vue в TypeScript, требуется шим
declare module '*.vue' {
  import Vue from 'vue';
  export default Vue;
}

// Определение типа модуля TypeScript, требуемого vue-template-loader
declare module '*.html' {
  import Vue, { ComponentOptions } from 'vue';

  interface WithRender {
    <V extends Vue>(options: ComponentOptions<V>): ComponentOptions<V>
    <V extends typeof Vue>(component: V): V
  }

  const withRender: WithRender
  export = withRender
}

Использование в файлах JavaScript/TypeScript

Теперь давайте создадим файл с шаблоном с названием nest.html:

<div class="nest">
  <p>{{ text }}</p>
  <button type="button" @click="baz()">Нажми на меня!</button>
</div>

Теперь давайте добавим файл nest.js, использующий nest.html. Мы может использовать vue-template-loader с или без декораторов класса, используя es6 с Vue:

// Без декораторов класса в JavaScript
import withRender from './nest.html';

export default withRender({
  data () {
    return {
      text: 'Я крокодил'
    };
  },
  methods: {
    baz () {
      console.log('Кнопка нажата!');
    };
  };
});

// С декораторами
import Vue from 'vue';
import Component from 'vue-class-component';
import WithRender from './nest.html';

@WithRender
@Component
export default class Nest extends Vue {
  text = 'Я крокодил!';

  baz() {
    console.log('Кнопка нажата!');
  }
}

Его также можно использовать в TypeScript следующим образом в файле nest.ts:

import Vue from 'vue';
import { Component } from 'vue-property-decorator';
import WithRender from './nest.html';

@WithRender
@Component({})
export default class NestComponent extends Vue {
  data() {
    return {
      text: 'Я крокодил!'
    }
  };

  baz() {
    console.log('Кнопка нажата!');
  }
};

Вывод

Использование vue-template-loader обеспечивает отличную поддержку TypeScript, а также может уменьшить количество компилируемых файлов, так как исключаются файлы .vue. Наконец, это очень легко понять людьми, работающими с Angular.

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Статья на GitHub

Использование vue-template-loader с Vue.js для компиляции шаблонов HTML was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.

Компоненты Vue великолепны, не так ли? Они инкапсулируют представление и поведение приложения в красивые небольшие компонуемые части. Если вам нужна небольшая дополнительная функциональность, просто присоедините директивы! Дело в том, что директивы довольно негибкие и не подходят для всего. Например, директивы не могут (казалось бы самое простое?) генерировать события. Что ж, это Vue, конечно, есть решение — абстрактные компоненты!

Абстрактные компоненты похожи на обычные компоненты, за исключением того, что они ничего отрисовывают в DOM. Они просто добавляют дополнительное поведение к существующим. Вам наверняка знакомы встроенные абстрактные компоненты Vue, такие как <transition>, <component> и <slot>.

Отличный вариант использования абстрактных компонентов наблюдается, когда элемент входит в область просмотра с помощью IntersectionObserver. Давайте посмотрим на реализацию простого абстрактного компонента для обработки этого.

Если вам нужна соответствующая готовая для продакшена реализация, взгляните на vue-intersect, на котором основана эта статья.

Приступаем к работе

Сначала создадим быстрый компонент, который просто отрисовывает его содержимое. Для этого мы ненадолго посмотрим на функции отрисовки.

Файл IntersectionObserver.vue:

export default {
   // Включает абстрактный компонент во Vue.
   // Это свойство не задокументировано и может изменить в любой момент,
   // но ваш компонент должен работать без него.
  abstract: true,
  // Ура, функции отрисовки!
  render() {
    // Без компонента-обёртки, мы можем отрисовать только один дочерний компонент.
    try {
      return this.$slots.default[0];
    } catch (e) {
      throw new Error('IntersectionObserver.vue может отрисовывать один и только один дочерний компонент.');
    }

    return null;
  }
}

Поздравляем! У вас теперь есть абстрактный компонент, который, ну, ничего не делает! Отрисовкой занимается дочерний компонент.

Добавление IntersectionObserver

Хорошо, теперь давайте придерживаться логики для IntersectionObserver.

Внимание: IntersectionObserver изначально не поддерживается IE или Safari, поэтому вам может для него полифил.

Файл IntersectionObserver.vue:

export default {
  // Остальной код из предыдущего листинга...

  mounted () {
    // Нет реальной потребности объявлять наблюдателя в качестве свойства данных,
    // потому что он не должен быть реактивным.

    this.observer = new IntersectionObserver((entries) => {
      this.$emit(entries[0].isIntersecting ? 'intersect-enter' : 'intersect-leave', [entries[0]]);
    });

    // Нужно подождать следующего тика для того, чтобы дочерний элемент мог отрисоваться.
    this.$nextTick(() => {
      this.observer.observe(this.$slots.default[0].elm);
    });
  }
}

Хорошо, теперь у нас есть абстрактный компонент, который можно использовать следующий образом:

<intersection-observer @intersect-enter="handleEnter" @intersect-leave="handleLeave">
  <my-honest-to-goodness-component></my-honest-to-goodness-component>
</intersection-observer>

Однако, это ещё не конец.

Заканчиваем

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

export default {
  // Остальной код из предыдущих листингов...
  
  destroyed() {
    // Кстати, почему W3C выбрало "disconnect" для названия метода?
    this.observer.disconnect();
  }
}

И в качестве бонусных очков, давайте добавим настраиваемый порог видимости элемента (threshold) для наблюдателя с помощью входных данных.

Файл IntersectionObserver.vue:

export default {
// Остальной код из предыдущих листингов...

  // Входные данные работают отлично в абстрактных компонентов!
  props: {
    threshold: {
      type: Array
    }
  },
  
  // Остальной код из предыдущих листингов...
  
  this.observer = new IntersectionObserver((entries) => {
    this.$emit(entries[0].isIntersecting ? 'intersect-enter' : 'intersect-leave', [entries[0]]);
  }, {
    threshold: this.threshold || 0
  });
  
  // Остальной код из предыдущих листингов...
}

Полный код IntersectionObserver.vue можно найти здесь

Окончательное использование будет выглядит так:

<intersection-observer @intersect-enter="handleEnter" @intersect-leave="handleLeave" :threshold="[0, 0.5, 1]">
  <my-honest-to-goodness-component></my-honest-to-goodness-component>
</intersection-observer>

Вот так, ваш первый абстрактный компонент!

Большое спасибо Thomas Kjærgaard / Heavyy за первоначальную реализацию и идею!

Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook. Статья на GitHub

Написание абстрактных компонентов во Vue.js was originally published in devSchacht on Medium, where people are continuing the conversation by highlighting and responding to this story.