Добрый день! Меня зовут Александр, я работаю frontend-разработчиком в компании Nord Clan. В прошлой статье мы рассмотрели процесс компиляции Vue, а теперь надо как-то «пристроить» результат этой самой компиляции в процесс рендеринга.

Дизайн лого: Марина Четвертакова

Нео проснулся от бликов вспыхнувшего экрана компьютера. Экран заполняла зеленая полоска прогресса.

– Матрица – испуганно прошептал Нео.

– Александр, вы уснули на работе – прошептал тимлид.

Я взглянул на экран компьютера еще раз. Компиляция Vue была завершена. Я облегченно вздохнул.

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

Однако при таком обилии функций и технологий легко упустить самые мощные из них. Если ваша цель — повысить производительность или упростить поддержку кода, эти продвинутые техники дадут вам серьёзное преимущество.

Давайте разберём 7 продвинутых техник в JavaScript, которые помогут вам вывести свои навыки на новый уровень.

Будучи консультантом по тестированию, я за годы работы прочитал массу статей по QA. Большинство из них — это в какой-то степени полезные, но часто случайные материалы, которые не всегда стоят времени. Но иногда я натыкался на удивительно хорошие статьи, которые действительно могут помочь улучшить навыки написания тестов. Я отобрал эти статьи и написал к ним аннотации. Половина из них относится непосредственно к JavaScript / Node.js, вторая половина охватывает общие концепции тестирования, которые применимы в любом языке.

Привет! Меня зовут Виталий, я тимлид в KTS, и за годы работы я провел больше 100 собеседований.

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

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

RStudio, R Markdown, Latex и отчеты в PDF формате. Мой опыт.

Сегодня я хочу рассказать о том, как я писал отчеты на R, с чем сталкивался и как решал проблемы, которые возникали по ходу разработки. Отчеты были в формате PDF и запускались из Python в Camunda.

Как лучше всего структурировать приложение Vue.js, чтобы оно масштабировалось и оставалось обслуживаемым и расширяемым по мере его роста? Этот вопрос я слышал неоднократно, и думаю, что один из ответов на него кроется в принципе предсказуемости. Когда речь идет о создании масштабируемого проекта, вы хотите, чтобы все в нем было максимально предсказуемо.

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

Почему это важно? Вы наверняка сталкивались с ситуацией, когда получали в наследство проект или были введены в него, а затем при выполнении первой задачи открывали кодовую базу и думали: "Я даже не знаю, с чего начать!".

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

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

В мае на Google I/O мы впервые увидели Material Design 2.0. Команда Google провела крупный рефакторинг и выпустила обновленную библиотеку дизайна. В ней появились новые компоненты и анимации. Мы следим за развитием Material Components с самого начала. Сейчас все находится на стадии RC1, и уже скоро выйдет в релиз. Под катом обзор новых и обновленных UI-компонентов для тех, кто еще не пробовал их в работе, но интересуется.

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

Тут мы сосредоточимся на работе в Figma и приёмами, что позволяют сделать всё правильно.

Это глава 44 раздела «SDK и UI-библиотеки» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Перейдём к более предметному разговору и попробуем объяснить, почему требование возможности замены одной из подсистем компонента приводит к кратному усложнению интерфейсов. Продолжим рассматривать пример компонента SearchBox из предыдущей главы. Напомним, что мы выделили следующие факторы, осложняющие проектирование API визуальных компонентов:

Введение в состав SDK UI-компонентов обогащает и так не самую простую конструкцию из клиент-серверного API и клиентской библиотеки дополнительным измерением: теперь с вашим API взаимодействуют одновременно и разработчики (которые написали код приложения), и пользователи (которые используют приложение). Хотя это изменение на первый взгляд может показаться не очень значительным, с точки зрения дизайна API добавление конечного пользователя — огромная проблема, которая требует на порядок более глубокой и качественной проработки дизайна программных интерфейсов по сравнению с «чистым» клиент-серверным API. Попробуем объяснить, почему так происходит, на конкретном примере.

Всем привет! Меня зовут Артур, я работаю frontend-разработчиком в Exness. Не так давно мы перевели один из наших проектов на веб-компоненты. Расскажу, с какими проблемами пришлось столкнуться, и о том, как многие концепции, к которым мы привыкли при работе с фреймворками, легко перекладываются на веб-компоненты.

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

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

Эта статья во многом вдохновлена докладом Павла Силина на РИТ 2017, однако здесь много моего собственного опыта и размышлений. Примеры будут на React + TypeScript, однако подход не привязан к какой-либо технологии.

История вопроса

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

Мне уже давно и прочно нравится мир Vue. Особенно завораживает скорость, с которой в нём рождаются новые возможности писать код более лёгким и понятным. Недавно появились Composition API, VueUse, Vite… По ходу освоения этих новых инструментов я нашёл шаблон Vitesse, буквально насыщенный удобными средствами — и для управления макетами (layout), и для маршрутизации, и для локализации и ещё для много чего… Возможно, есть смысл написать отдельный обзор этого арсенала по русски (чего в Интернете пока ещё нет). Но сейчас речь не об этом.

Vue 3 принёс в жизнь разработчиков возможность организации более гибкой структуры приложений. Всё чаще я стал замечать, что разные команды, а порой и разработчики внутри одной, используют целый зоопарк сомнительных подходов для организации взаимодействия между компонентами. Применяются какие-то крайности, либо всё в state manager, либо в composable (composition API), либо мутация props внутри дочерних компонентов!

Хотелось бы поднять эту тему и рассмотреть варианты взаимодействия компонентов доступные нам во Vue 3.