Всем привет! На этой неделе продолжим разговор о доступности и поговорим о спецификации, позволяющей вам быстро и просто повысить доступность интерфейса не только для нового кода, но и в текущих проектах в рамках поддержки. С вами буду я, Артём, frontend-разработчик.
👌Повышаем доступность: WAI-ARIA
Спецификация ARIA или Accessible Rich Internet Applications - это простой и понятный разработчику инструмент. ARIA можно разделить на две основных секции: это role-атрибуты и собственно aria-атрибуты.
🦹♀️🦸♀️Роли
Ранее мы обсуждали необходимость применения семантической разметки в html. Самое простое, что могут предоставить role-атрибуты - это определить семантику для «чистых» элементов вроде div или span. Важный момент: речь идет только о семантике, но не о поведении или стилизации.
Например, вы можете передать элементу атрибут role="main", role="navigation" и т. д., и он станет семантически эквивалентным тегу main или nav.
Или в вашем приложении есть форма, которая работает по ajax, но по той или иной причине она не является элементом form, при помощи ARIA вы можете снабдить форму атрибутом role="form".
🗿Это так называемые landmark roles. Но задачи role-атрибутов не ограничиваются композицией и семантикой.
🚨Например, атрибуты role="alert", role="alertdialog", role="dialog" могут маркировать динамические элементы, появляющиеся на странице как реакция на действия пользователя. Первый предусмотрен для всплывающих уведомлений (об ошибке или об успешном действии), второй и третий – для обработки диалогового или модального окна, то есть для случаев, когда нужно не только максимально быстро уведомить пользователя о чем-то, но еще и получить от него фидбэк. Браузер будет обрабатывать содержимое таких элементов только тогда, когда они видимы, и игнорировать, если для них установлен display: none или visibility: hidden.
🖲Также не забудем о любимом многими role="button", который позволит сделать из любого div’а кнопку. Не совсем полноценную, а потому частичную обработку состояний вам нужно будет взять на себя. Например, состояние disabled на role="button" не реализуется браузером нативно, но такой элемент уже может получать фокус, что уже лучше, чем ничего.
#rdclr_frontend
👌Повышаем доступность: WAI-ARIA
Спецификация ARIA или Accessible Rich Internet Applications - это простой и понятный разработчику инструмент. ARIA можно разделить на две основных секции: это role-атрибуты и собственно aria-атрибуты.
🦹♀️🦸♀️Роли
Ранее мы обсуждали необходимость применения семантической разметки в html. Самое простое, что могут предоставить role-атрибуты - это определить семантику для «чистых» элементов вроде div или span. Важный момент: речь идет только о семантике, но не о поведении или стилизации.
Например, вы можете передать элементу атрибут role="main", role="navigation" и т. д., и он станет семантически эквивалентным тегу main или nav.
Или в вашем приложении есть форма, которая работает по ajax, но по той или иной причине она не является элементом form, при помощи ARIA вы можете снабдить форму атрибутом role="form".
🗿Это так называемые landmark roles. Но задачи role-атрибутов не ограничиваются композицией и семантикой.
🚨Например, атрибуты role="alert", role="alertdialog", role="dialog" могут маркировать динамические элементы, появляющиеся на странице как реакция на действия пользователя. Первый предусмотрен для всплывающих уведомлений (об ошибке или об успешном действии), второй и третий – для обработки диалогового или модального окна, то есть для случаев, когда нужно не только максимально быстро уведомить пользователя о чем-то, но еще и получить от него фидбэк. Браузер будет обрабатывать содержимое таких элементов только тогда, когда они видимы, и игнорировать, если для них установлен display: none или visibility: hidden.
🖲Также не забудем о любимом многими role="button", который позволит сделать из любого div’а кнопку. Не совсем полноценную, а потому частичную обработку состояний вам нужно будет взять на себя. Например, состояние disabled на role="button" не реализуется браузером нативно, но такой элемент уже может получать фокус, что уже лучше, чем ничего.
#rdclr_frontend
👍5
ARIA-атрибуты можно условно разделить на описательные атрибуты и атрибуты состояния.
✍️Описательные атрибуты
Пожалуй, самым часто используемым на практике атрибутом является aria-label, он позволяет привязать к элементу текстовое описание, если он сам не может (или не хочет) иметь свой текст.
🏷А вот aria-labelledby позволяет не указывать отдельный текст, а привязать к элементу текст из другого элемента по его id (что-то вроде атрибута for у label’а, только наоборот). Это бывает очень удобно для того, чтобы описать группу элементов, например, группу радиокнопок.
⚠️Атрибут aria-errormessage хоть и работает только в паре с атрибутом состояния aria-invalid, все же выполняет функцию описания: он как и aria-labelledby ссылается на элемент, который содержит текст ошибки. Его можно присваивать элементам формы, но браузер будет его игнорировать до тех пор, пока атрибут aria-invalid этого элемента не получит true.
🚦Атрибуты состояний
К этой категории относятся, например, такие атрибуты, как aria-checked, aria-selected, aria-disabled, aria-hidden, aria-invalid, aria-expanded и многие другие. Они используются для маркирования состояний динамических блоков: пометка активного таба или выбранной опции в списке, пометка развернутого аккордеона, скрытого контента и т. д. Так как речь идет о состояниях, то управлять ими приходится динамически при помощи javascript.
🚀С помощью атрибутов мы также можем управлять тем, как скринридер будет реагировать на динамические изменения. За это отвечают aria-live, aria-atomic, aria-relevant и aria-busy.
#rdclr_frontend
✍️Описательные атрибуты
Пожалуй, самым часто используемым на практике атрибутом является aria-label, он позволяет привязать к элементу текстовое описание, если он сам не может (или не хочет) иметь свой текст.
🏷А вот aria-labelledby позволяет не указывать отдельный текст, а привязать к элементу текст из другого элемента по его id (что-то вроде атрибута for у label’а, только наоборот). Это бывает очень удобно для того, чтобы описать группу элементов, например, группу радиокнопок.
⚠️Атрибут aria-errormessage хоть и работает только в паре с атрибутом состояния aria-invalid, все же выполняет функцию описания: он как и aria-labelledby ссылается на элемент, который содержит текст ошибки. Его можно присваивать элементам формы, но браузер будет его игнорировать до тех пор, пока атрибут aria-invalid этого элемента не получит true.
🚦Атрибуты состояний
К этой категории относятся, например, такие атрибуты, как aria-checked, aria-selected, aria-disabled, aria-hidden, aria-invalid, aria-expanded и многие другие. Они используются для маркирования состояний динамических блоков: пометка активного таба или выбранной опции в списке, пометка развернутого аккордеона, скрытого контента и т. д. Так как речь идет о состояниях, то управлять ими приходится динамически при помощи javascript.
🚀С помощью атрибутов мы также можем управлять тем, как скринридер будет реагировать на динамические изменения. За это отвечают aria-live, aria-atomic, aria-relevant и aria-busy.
#rdclr_frontend
🔥5👍3
👨💻Сегодня немного практических примеров👩💻
1️⃣Дизайнер нарисовал поп-ап с каким-то контентом и классическим крестиком в углу, чтобы его можно было закрыть. См. первый пример — в листинге реализация кнопки с крестиком, которая не нарушает принципы доступности.
2️⃣В одном из прошлых постов я показывал пример формы с нативными элементами. Теперь представим ситуацию, когда мы точно знаем, что по тем или иным причинам мы не можем использовать нативные элементы, поэтому все контролы мы будем кастомить. При помощи aria-атрибутов мы можем это реализовать, не ухудшая их доступность. Однако следует помнить, что теперь абсолютно всё поведение элементов вам нужно будет реализовывать при помощи javascript.
3️⃣Такая структура, как табы, не имеет нативного семантического представления. Кроме того было бы логично представить табы как набор секций со своей структурой контента внутри, переключаемых кнопками. При помощи role-атрибутов мы можем добавить им семантики и повысить доступность.
#rdclr_frontend
1️⃣Дизайнер нарисовал поп-ап с каким-то контентом и классическим крестиком в углу, чтобы его можно было закрыть. См. первый пример — в листинге реализация кнопки с крестиком, которая не нарушает принципы доступности.
2️⃣В одном из прошлых постов я показывал пример формы с нативными элементами. Теперь представим ситуацию, когда мы точно знаем, что по тем или иным причинам мы не можем использовать нативные элементы, поэтому все контролы мы будем кастомить. При помощи aria-атрибутов мы можем это реализовать, не ухудшая их доступность. Однако следует помнить, что теперь абсолютно всё поведение элементов вам нужно будет реализовывать при помощи javascript.
3️⃣Такая структура, как табы, не имеет нативного семантического представления. Кроме того было бы логично представить табы как набор секций со своей структурой контента внутри, переключаемых кнопками. При помощи role-атрибутов мы можем добавить им семантики и повысить доступность.
#rdclr_frontend
🔥2
👩💻Инструменты разработчика
Сегодня расскажу немного об инструментах, которые позволят вам легче разрабатывать и тестировать интерфейсы с точки зрения их доступности.
🛠Браузерные тулзы
Первое, на что стоит обратить внимание, это те средства, которые поставляют сами разработчики браузеров: в Chrome и FireFox есть неплохие «Инспекторы доступности», которые позволяют исследовать дерево и такие вещи как контрастность цветов по отношению к фону. Кроме того, в Google Chrome встроен мощный инструмент Lighthouse, который может проводить аудит не только по производительности и Web Vitals, но и по доступности.
🌐Браузерные расширения
Инструменты аудита доступности чаще всего поставляются в виде браузерного расширения. Сюда относятся такие штуки, как Axe DevTools, Accessibility Insights и Wave от организации WebAIM. Попробуйте что-нибудь из этого списка и проведите для примера аудиты нескольких страниц в своих проектах, чтобы выбрать удобный для себя инструмент.
📺Скринридеры
В предыдущих постах я часто упоминал скринридеры, и для разработчика это тоже инструмент. С его помощью вы можете сами услышать, как подобные приложения «озвучивают» дерево доступности вашего интерфейса. В первую очередь обратите внимание на средства от разработчиков ОС: в состав системы macOS включен VoiceOver, а для Windows есть диктор Windows Narrator. Также существуют скрин-ридеры в виде браузерных расширений, например, Chrome Vox или Screen Reader от Google или Read Aloud, встроенный в Microsoft Edge.
⌨Ну, и самый основной инструмент, как это ни странно, – это ваша клавиатура 😊Если вы можете беспрепятственно взаимодействовать с вашим интерфейсом при помощи клавиатуры – это уже большая победа.
#rdclr_frontend
Сегодня расскажу немного об инструментах, которые позволят вам легче разрабатывать и тестировать интерфейсы с точки зрения их доступности.
🛠Браузерные тулзы
Первое, на что стоит обратить внимание, это те средства, которые поставляют сами разработчики браузеров: в Chrome и FireFox есть неплохие «Инспекторы доступности», которые позволяют исследовать дерево и такие вещи как контрастность цветов по отношению к фону. Кроме того, в Google Chrome встроен мощный инструмент Lighthouse, который может проводить аудит не только по производительности и Web Vitals, но и по доступности.
🌐Браузерные расширения
Инструменты аудита доступности чаще всего поставляются в виде браузерного расширения. Сюда относятся такие штуки, как Axe DevTools, Accessibility Insights и Wave от организации WebAIM. Попробуйте что-нибудь из этого списка и проведите для примера аудиты нескольких страниц в своих проектах, чтобы выбрать удобный для себя инструмент.
📺Скринридеры
В предыдущих постах я часто упоминал скринридеры, и для разработчика это тоже инструмент. С его помощью вы можете сами услышать, как подобные приложения «озвучивают» дерево доступности вашего интерфейса. В первую очередь обратите внимание на средства от разработчиков ОС: в состав системы macOS включен VoiceOver, а для Windows есть диктор Windows Narrator. Также существуют скрин-ридеры в виде браузерных расширений, например, Chrome Vox или Screen Reader от Google или Read Aloud, встроенный в Microsoft Edge.
⌨Ну, и самый основной инструмент, как это ни странно, – это ваша клавиатура 😊Если вы можете беспрепятственно взаимодействовать с вашим интерфейсом при помощи клавиатуры – это уже большая победа.
#rdclr_frontend
👍9
📕Что почитать о доступности
1️⃣Интерактивные примеры по конкретным атрибутам ARIA на сайте w3c. Переходим в интересующий раздел, открываем devtools и изучаем структуру страницы.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/
2️⃣Достаточно полный справочник MDN по role- и aria-атрибутам.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques
3️⃣Пример реализации focus trapping на сайте w3c.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
4️⃣Но не забываем про inert-polyfill, с ним это реализовать гораздо проще, плюс в будущем он может быть реализован нативно.
https://github.com/WICG/inert
5️⃣Хорошие примеры нативных элементов форм. Если вам нужны стилизованные формы с полными нативными возможностями без js-а.
http://wtfforms.com/
6️⃣В продолжение темы — опенсорсная либа паттернов, реализующих доступность, с примерами и демками.
https://a11y-style-guide.com/style-guide/
#rdclr_frontend #read
1️⃣Интерактивные примеры по конкретным атрибутам ARIA на сайте w3c. Переходим в интересующий раздел, открываем devtools и изучаем структуру страницы.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/
2️⃣Достаточно полный справочник MDN по role- и aria-атрибутам.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques
3️⃣Пример реализации focus trapping на сайте w3c.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
4️⃣Но не забываем про inert-polyfill, с ним это реализовать гораздо проще, плюс в будущем он может быть реализован нативно.
https://github.com/WICG/inert
5️⃣Хорошие примеры нативных элементов форм. Если вам нужны стилизованные формы с полными нативными возможностями без js-а.
http://wtfforms.com/
6️⃣В продолжение темы — опенсорсная либа паттернов, реализующих доступность, с примерами и демками.
https://a11y-style-guide.com/style-guide/
#rdclr_frontend #read
👍5
Ревью кода: кросс-ревью. Практики тим-лидов
Итак. Сегодня я хочу коснуться направления тимлидерства, а в частности этапа разработки называемого Ревью кода.
На своем опыте встречал совершенно разное отношение к этой церемонии:
- кто-то считает, что код нужно поставлять быстро и на ревью нет времени;
- кто-то считает, что код нужно ревьюить, но не всегда;
- кто-то считает, что в команде есть ведущий сеньор или тим-лид, и только он имеет право ревьюить чужой код.
Однако, мое мнение, что все вышеперечисленное абсолютно неверно и на всех своих проектах стараюсь вводить такую практику как кросс-ревью.
🦀 Кросс-ревью — это проверка кода всеми членами команды.
А теперь как в Турецком сериале: «Самое интересное в следующей серии» 😉
#teamlead #rdclr_backend #rdclr_frontend
Итак. Сегодня я хочу коснуться направления тимлидерства, а в частности этапа разработки называемого Ревью кода.
На своем опыте встречал совершенно разное отношение к этой церемонии:
- кто-то считает, что код нужно поставлять быстро и на ревью нет времени;
- кто-то считает, что код нужно ревьюить, но не всегда;
- кто-то считает, что в команде есть ведущий сеньор или тим-лид, и только он имеет право ревьюить чужой код.
Однако, мое мнение, что все вышеперечисленное абсолютно неверно и на всех своих проектах стараюсь вводить такую практику как кросс-ревью.
🦀 Кросс-ревью — это проверка кода всеми членами команды.
А теперь как в Турецком сериале: «Самое интересное в следующей серии» 😉
#teamlead #rdclr_backend #rdclr_frontend
👍8❤2
В чем же преимущество концепции кросс-ревью?
🐗 В первую очередь, минимизируется шанс ошибок в поставляемом коде. Даже опытный разработчик может допускать небольшие ошибки по невнимательности, и даже разработчик без продакшн опыта может такие ошибки заметить.
🐧 Более того, при таком подходе к разработке происходят постоянные дискуссии между разработчиками на счет того какой подход лучше, а все мы знаем, что в спорах рождается истина.
🐌 Также, каждый член команды разработки находится up to date с последними изменениями в коде (которого, возможно, он даже раньше не касался).
Ну и самое главное! Даже если вы не находите ошибок (что на самом деле хорошо) или у вас нет предложений по улучшению, в любом случае при просмотре чужого кода всегда можно научиться чему-нибудь новому. 🪱 Если вы встертили что-то неизвестное вам, вы всегда можете задать несколько вопросов и расширить свои знания.
#teamlead #rdclr_frontend
🐗 В первую очередь, минимизируется шанс ошибок в поставляемом коде. Даже опытный разработчик может допускать небольшие ошибки по невнимательности, и даже разработчик без продакшн опыта может такие ошибки заметить.
🐧 Более того, при таком подходе к разработке происходят постоянные дискуссии между разработчиками на счет того какой подход лучше, а все мы знаем, что в спорах рождается истина.
🐌 Также, каждый член команды разработки находится up to date с последними изменениями в коде (которого, возможно, он даже раньше не касался).
Ну и самое главное! Даже если вы не находите ошибок (что на самом деле хорошо) или у вас нет предложений по улучшению, в любом случае при просмотре чужого кода всегда можно научиться чему-нибудь новому. 🪱 Если вы встертили что-то неизвестное вам, вы всегда можете задать несколько вопросов и расширить свои знания.
#teamlead #rdclr_frontend
👍6❤2
Вы подумали это все? А вот и нет =)
👍🏻 При кросс-ревью нет нагрузки на отдельного разработчика (тим-лида), который один должен пересмотреть все ревью.
👎🏻 Однако бывают случаи, когда разработчики, увидев, что более опытный разраб поставил аппрув, даже не уделяют внимания просмотру.
🚨 На такой случай есть суперский лайфхак: будучи тимлидом или ведущим разработчиком, вы можете специально допустить несколько ошибок в ревью, дабы проверить, кто добросовестно просматривает ваш код.
Всем тем, кто поставил аппрув не глядя, следует в доступной форме объяснить важность данной церемонии и попросить больше так не делать. Пара повторных подобных проверок (можно подговорить еще кого-нибудь из команды) — и ваш код будет просматриваться детальнее, чем сумка на таможне.
📮 В ходе повествования я упирался в слово «код», но такая практика может быть использована в команде абсолютно любого направления. И важно добавить, что под словом «команда» подразумевается отдельное направление (бэк, фронт, qa, дизайн и тд).
Правила всего 2:
1) желание развиваться и делать вашу работу все лучше и лучше;
2) команда от 3х человек и более (в случае 2х человек, само наличие ревью уже превращается в кросс-ревью).
Надеюсь, у всех вас на проектах существует кросс-ревью и вы ему рады. 😀
#teamlead #rdclr_frontend #rdclr_backend
👍🏻 При кросс-ревью нет нагрузки на отдельного разработчика (тим-лида), который один должен пересмотреть все ревью.
👎🏻 Однако бывают случаи, когда разработчики, увидев, что более опытный разраб поставил аппрув, даже не уделяют внимания просмотру.
🚨 На такой случай есть суперский лайфхак: будучи тимлидом или ведущим разработчиком, вы можете специально допустить несколько ошибок в ревью, дабы проверить, кто добросовестно просматривает ваш код.
Всем тем, кто поставил аппрув не глядя, следует в доступной форме объяснить важность данной церемонии и попросить больше так не делать. Пара повторных подобных проверок (можно подговорить еще кого-нибудь из команды) — и ваш код будет просматриваться детальнее, чем сумка на таможне.
📮 В ходе повествования я упирался в слово «код», но такая практика может быть использована в команде абсолютно любого направления. И важно добавить, что под словом «команда» подразумевается отдельное направление (бэк, фронт, qa, дизайн и тд).
Правила всего 2:
1) желание развиваться и делать вашу работу все лучше и лучше;
2) команда от 3х человек и более (в случае 2х человек, само наличие ревью уже превращается в кросс-ревью).
Надеюсь, у всех вас на проектах существует кросс-ревью и вы ему рады. 😀
#teamlead #rdclr_frontend #rdclr_backend
👍10❤2
Проекция в WebGL, или «алло а камера где дядя»
Когда я только начинал заниматься графикой (а точнее, на тот момент еще геймдевом), совсем зеленый и не нюхавший так сказать полигонов, я взялся за движок Blitz3D. Он был настолько прост, что даже для неподготовленного человека взять и собрать сцену было проще простого. Взял пространство, поставил туда камеру, повесил кубик и уже идешь хвалиться родителям, что ты Senior Graphics Developer. 😎 И вот ты приходишь в OpenGL (да, именно десктопный, про WebGL будет чуть позже) и думаешь «ну я уже все знаю, сейчас все быстренько накину, и все как обычно отрендерится!». Но начинающего разработчика графики ждало крупное разочарование.
На самом деле, в низкоуровневой графике вообще нет такого понятия, как камера. Все, что на самом деле умеет WebGL — это растрировать полигоны, переводя их координаты в экранное пространство.
💅🏻 Так как же это происходит, и что для этого нужно сделать?
WebGL представляет твой экран, как трехмерную координатную систему, где X смотрит вправо, Y вверх, а Z-координата направлена из монитора прямо на тебя (одна из самых нелогичных вещей для неподготовленного человека, так как во всех игровых движках Z обычно смотрит вглубь экрана). Если представить это все в виде куба, то его размеры будут от (-1, -1, -1) до (1, 1, 1), когда (0, 0, 0) будет центром экрана, а ребра этого куба будут краями экрана. И для того, чтобы наша моделька отобразилась, нужно всю ее геометрию преобразовать каким-то неведомым образом так, чтобы она вписывалась в этот куб, иначе мы рискуем отрисовать ее за пределами экрана. Я нарочно не упоминаю про Z-координату, так как не очень просто будет с наскока объяснить, что она из себя здесь представляет, но не волнуйтесь, чуть позже мы к ней вернемся.
🪢 Так как же нам обработать модель так, чтобы она оказалась в этом кубе?
На помощь нам придут матрицы (ну, которые математические, давайте без приколов).
Матрицы в WebGL представляют собой массив из 16 дробных чисел, в виде 4х4, в которых содержится информация о повороте, сдвиге и размере. И вот уже читатель начинает догадываться: «то есть нам надо построить какую-то специфическую матрицу, и уже на нее помножить все точки нашей модельки». И это абсолютно верно, с одной маленькой ремаркой — матриц у нас будет не одна, а целых три: матрица проекции, матрица отображения и матрица объекта. Давайте быстренько их и разберем.
#rdclr_frontend #WebGL
Когда я только начинал заниматься графикой (а точнее, на тот момент еще геймдевом), совсем зеленый и не нюхавший так сказать полигонов, я взялся за движок Blitz3D. Он был настолько прост, что даже для неподготовленного человека взять и собрать сцену было проще простого. Взял пространство, поставил туда камеру, повесил кубик и уже идешь хвалиться родителям, что ты Senior Graphics Developer. 😎 И вот ты приходишь в OpenGL (да, именно десктопный, про WebGL будет чуть позже) и думаешь «ну я уже все знаю, сейчас все быстренько накину, и все как обычно отрендерится!». Но начинающего разработчика графики ждало крупное разочарование.
На самом деле, в низкоуровневой графике вообще нет такого понятия, как камера. Все, что на самом деле умеет WebGL — это растрировать полигоны, переводя их координаты в экранное пространство.
💅🏻 Так как же это происходит, и что для этого нужно сделать?
WebGL представляет твой экран, как трехмерную координатную систему, где X смотрит вправо, Y вверх, а Z-координата направлена из монитора прямо на тебя (одна из самых нелогичных вещей для неподготовленного человека, так как во всех игровых движках Z обычно смотрит вглубь экрана). Если представить это все в виде куба, то его размеры будут от (-1, -1, -1) до (1, 1, 1), когда (0, 0, 0) будет центром экрана, а ребра этого куба будут краями экрана. И для того, чтобы наша моделька отобразилась, нужно всю ее геометрию преобразовать каким-то неведомым образом так, чтобы она вписывалась в этот куб, иначе мы рискуем отрисовать ее за пределами экрана. Я нарочно не упоминаю про Z-координату, так как не очень просто будет с наскока объяснить, что она из себя здесь представляет, но не волнуйтесь, чуть позже мы к ней вернемся.
🪢 Так как же нам обработать модель так, чтобы она оказалась в этом кубе?
На помощь нам придут матрицы (ну, которые математические, давайте без приколов).
Матрицы в WebGL представляют собой массив из 16 дробных чисел, в виде 4х4, в которых содержится информация о повороте, сдвиге и размере. И вот уже читатель начинает догадываться: «то есть нам надо построить какую-то специфическую матрицу, и уже на нее помножить все точки нашей модельки». И это абсолютно верно, с одной маленькой ремаркой — матриц у нас будет не одна, а целых три: матрица проекции, матрица отображения и матрица объекта. Давайте быстренько их и разберем.
#rdclr_frontend #WebGL
👍6❤3
Матрица проекции, матрица отображения и матрица объекта в WebGL
🪡 Матрица объекта — это самая простая в объяснении из всех трех. Допустим, у нас есть стул (ну, в реалиях WebGL это будет просто пачка вершин и треугольников, но давайте оперировать человеческим языком). И вот у нас появляется задача: нужно этот стул переставить в пространстве. Что мы будем делать? Правильно, запишем в матрицу объекта значения, на которые нам нужно подвинуть наш стул. Хотите повернуть его на 90 градусов? Правильно, запишем в матрицу данные о размерах. Стул слишком большой? Я думаю, можно не продолжать.
🧵 Матрица отображения — одна из самых неочевидных вещей, как и Z-координата. Казалось бы, если у нас есть камера, почему бы нам ее не направить на стул и поставить перед ним, и вот он успех, но нет. Не забываем, что для того, чтобы модель отрисовалась, нам нужно вписать ее в тот самый куб, который, к сожалению, двигать нельзя. И как же быть? Да очень просто, мы просто возьмем весь наш трехмерный мир и вместо камеры подвинем и перевернем его. Да, звучит странно, но именно так это и работает. Задумайтесь, во всех играх, в которые вы играли, не камера двигается по миру, а мир вращается и двигается вокруг камеры!
Есть небольшой лайфхак: для того, чтобы быстро построить такую матрицу, мы можем сначала построить матрицу, будто бы мы двигаем именно камеру, а потом инвертировать ее. Если коротко объяснить инверсию матрицы в WebGL, она создает копию ваших преобразований, но наоборот. Например, вы увеличиваете стул в два раза, а инверсная матрица будет его в два раза уменьшать. Подвинули вперед? Инверсная подвинет назад и так далее.
🧶 Что же касается матрицы проекции — это одна из самых сложных в понимании матриц. Она делает так, что пространство как бы сплющивается при ухождении в глубину. Именно за счет нее достигается перспектива (это если мы говорим про перспективную проекцию, существует так же ортографическая проекция, но про нее как-нибудь в другой раз). Здесь же я бы рассказал про Z-координату нашего куба и почему она вообще существует, но про это мы поговорим уже в другом посте, про экранные буфферы.
Постарался разжевать как мог, но я думаю, что не все разберутся с наскока, поэтому жду ваших вопросов и комментариев, будем разбираться вместе!
#rdclr_frontend #WebGL
🪡 Матрица объекта — это самая простая в объяснении из всех трех. Допустим, у нас есть стул (ну, в реалиях WebGL это будет просто пачка вершин и треугольников, но давайте оперировать человеческим языком). И вот у нас появляется задача: нужно этот стул переставить в пространстве. Что мы будем делать? Правильно, запишем в матрицу объекта значения, на которые нам нужно подвинуть наш стул. Хотите повернуть его на 90 градусов? Правильно, запишем в матрицу данные о размерах. Стул слишком большой? Я думаю, можно не продолжать.
🧵 Матрица отображения — одна из самых неочевидных вещей, как и Z-координата. Казалось бы, если у нас есть камера, почему бы нам ее не направить на стул и поставить перед ним, и вот он успех, но нет. Не забываем, что для того, чтобы модель отрисовалась, нам нужно вписать ее в тот самый куб, который, к сожалению, двигать нельзя. И как же быть? Да очень просто, мы просто возьмем весь наш трехмерный мир и вместо камеры подвинем и перевернем его. Да, звучит странно, но именно так это и работает. Задумайтесь, во всех играх, в которые вы играли, не камера двигается по миру, а мир вращается и двигается вокруг камеры!
Есть небольшой лайфхак: для того, чтобы быстро построить такую матрицу, мы можем сначала построить матрицу, будто бы мы двигаем именно камеру, а потом инвертировать ее. Если коротко объяснить инверсию матрицы в WebGL, она создает копию ваших преобразований, но наоборот. Например, вы увеличиваете стул в два раза, а инверсная матрица будет его в два раза уменьшать. Подвинули вперед? Инверсная подвинет назад и так далее.
🧶 Что же касается матрицы проекции — это одна из самых сложных в понимании матриц. Она делает так, что пространство как бы сплющивается при ухождении в глубину. Именно за счет нее достигается перспектива (это если мы говорим про перспективную проекцию, существует так же ортографическая проекция, но про нее как-нибудь в другой раз). Здесь же я бы рассказал про Z-координату нашего куба и почему она вообще существует, но про это мы поговорим уже в другом посте, про экранные буфферы.
Постарался разжевать как мог, но я думаю, что не все разберутся с наскока, поэтому жду ваших вопросов и комментариев, будем разбираться вместе!
#rdclr_frontend #WebGL
🔥15❤3
Типы конвейеров в WebGL — шейдеры/1
Опять начну пост с исторической справки: когда я начинал щупать OpenGL, для общего понимания все предлагали использовать фиксированный конвейер, хотя в это время уже вовсю были распространены шейдеры.
Что же это вообще такое? Давайте разбираться.
Сначала давайте определимся с общим понятием конвейера. 🏭 В нашем случае, конвейер — это некая последовательность действий, которую нам в связке с видяхой нужно совершить, чтобы вывести графику на экран (давайте пока ограничимся той же моделькой стула из предыдущего поста).
Так как OpenGL (как и WebGL) является по сути процедурной стейт-машиной, перед каждой отрисовкой нам нужно объяснить ему, что нам нужно, что нет, какие режимы включить и так далее. Когда мы работаем с фиксированным конвейером, общая последовательность действий такая:
- Установить все три матрицы из прошлого поста - model, view & projection.
- Включить текстурирование, привязать текстуру стула.
- Отправить данные о вершинах на видяху.
- Привязать эти данные в отрисовку.
- Настроить светильники.
- Вызвать отрисовку.
- Отключить светильники, отвязать данные вершин, отключить текстурирование.
И вот эта последовательность действий у нас выполняется каждый кадр для каждой модели. Казалось бы, все логично, но фиксированный конвейер накладывает свои ограничения:
💣 1. Мы ограничены в светильниках, максимум — 8
🔮 2. Мы не можем влиять на отрисовку, все растрирование лежит на зашитых алгоритмах
🧿 3. Сложно сделать красиво, в основном приходится прибегать к хакам
И в какой-то момент ребята подумали, и решили: а почему бы нам не дать разработчикам возможность настраивать рендер целиком? Так появились шейдеры (ждите, ща второй пост).
#rdclr_frontend #WebGL
Опять начну пост с исторической справки: когда я начинал щупать OpenGL, для общего понимания все предлагали использовать фиксированный конвейер, хотя в это время уже вовсю были распространены шейдеры.
Что же это вообще такое? Давайте разбираться.
Сначала давайте определимся с общим понятием конвейера. 🏭 В нашем случае, конвейер — это некая последовательность действий, которую нам в связке с видяхой нужно совершить, чтобы вывести графику на экран (давайте пока ограничимся той же моделькой стула из предыдущего поста).
Так как OpenGL (как и WebGL) является по сути процедурной стейт-машиной, перед каждой отрисовкой нам нужно объяснить ему, что нам нужно, что нет, какие режимы включить и так далее. Когда мы работаем с фиксированным конвейером, общая последовательность действий такая:
- Установить все три матрицы из прошлого поста - model, view & projection.
- Включить текстурирование, привязать текстуру стула.
- Отправить данные о вершинах на видяху.
- Привязать эти данные в отрисовку.
- Настроить светильники.
- Вызвать отрисовку.
- Отключить светильники, отвязать данные вершин, отключить текстурирование.
И вот эта последовательность действий у нас выполняется каждый кадр для каждой модели. Казалось бы, все логично, но фиксированный конвейер накладывает свои ограничения:
💣 1. Мы ограничены в светильниках, максимум — 8
🔮 2. Мы не можем влиять на отрисовку, все растрирование лежит на зашитых алгоритмах
🧿 3. Сложно сделать красиво, в основном приходится прибегать к хакам
И в какой-то момент ребята подумали, и решили: а почему бы нам не дать разработчикам возможность настраивать рендер целиком? Так появились шейдеры (ждите, ща второй пост).
#rdclr_frontend #WebGL
🔥2
Типы конвейеров в WebGL — шейдеры/2
Если коротко, то шейдер — это маленькая программка на C-подобном языке, которая сначала выполняется для каждой вершины, а потом для каждого пикселя модели на экране, и определяет какой цвет должен быть в этом пикселе.
Благодаря шейдерам нам становится доступен огромнейший пласт эффектов, ведь теперь мы не ограничены растрированием со стороны OpenGL.
Однако, шейдерный конвейер автоматически указывает нам, что все прошлые манипуляции со стороны программы становятся устаревшими, и нужно внести некоторые коррективы, которые на самом деле ускорят наш рендер.
💛 Вся матричная математика уезжает на видеокарту — не просто так у нее есть compute-ядра, которые считают перемножения матриц в сотни раз быстрее ЦП, тут и выигрыш.
💙 Освещение целиком и полностью ложится на программиста, так как на пиксели, которые выводит шейдер, не распространяется фиксированный конвейер.
💜 Наложение текстуры тоже теперь должно считаться на видяхе, делается очень просто, но мы можем полностью контролировать какой пиксель с текстуры брать для текущего пикселя.
🤎 Мы можем передавать в шейдеры какие угодно данные: как общие, например текущий цвет освещения, так и повершинные, например текстурная координата этой вершины.
❤️ Вершинный и фрагментный (попиксельный) шейдеры могут обмениваться информацией для удобства рендера.
Но лучше всего будет объяснить это наглядно, чем мы и займемся в следующем посте. 👀
#rdclr_frontend #WebGL
Если коротко, то шейдер — это маленькая программка на C-подобном языке, которая сначала выполняется для каждой вершины, а потом для каждого пикселя модели на экране, и определяет какой цвет должен быть в этом пикселе.
Благодаря шейдерам нам становится доступен огромнейший пласт эффектов, ведь теперь мы не ограничены растрированием со стороны OpenGL.
Однако, шейдерный конвейер автоматически указывает нам, что все прошлые манипуляции со стороны программы становятся устаревшими, и нужно внести некоторые коррективы, которые на самом деле ускорят наш рендер.
💛 Вся матричная математика уезжает на видеокарту — не просто так у нее есть compute-ядра, которые считают перемножения матриц в сотни раз быстрее ЦП, тут и выигрыш.
💙 Освещение целиком и полностью ложится на программиста, так как на пиксели, которые выводит шейдер, не распространяется фиксированный конвейер.
💜 Наложение текстуры тоже теперь должно считаться на видяхе, делается очень просто, но мы можем полностью контролировать какой пиксель с текстуры брать для текущего пикселя.
🤎 Мы можем передавать в шейдеры какие угодно данные: как общие, например текущий цвет освещения, так и повершинные, например текстурная координата этой вершины.
❤️ Вершинный и фрагментный (попиксельный) шейдеры могут обмениваться информацией для удобства рендера.
Но лучше всего будет объяснить это наглядно, чем мы и займемся в следующем посте. 👀
#rdclr_frontend #WebGL
🔥3😱1
Разбираем тени / 1 (простой пример работы шейдеров)
Из-за того, что Blitz3D, с которого я начинал знакомство с графикой, не сильно был способен реализовать какие-либо графические эффекты (а связано это было с тем, что он был довольно старым и использовал под капотом Direct3D 7), меня всегда впечатляли приемы, которые использовали «взрослые» игры, например — тени. 👣
Если мы соберем сцену с улицей, она будет казаться неполной и плоской, так как обычно мы привыкли видеть тень от солнца на всех объектах. И как оказалось, тень от солнца является одним из самых простых эффектов, который можно реализовать с помощью шейдеров. Как же оно работает?
На самом деле, чтобы представить и посчитать тени, мы должны подумать немного нестандартно, и представить: «а что бы мы видели, если бы именно мы были солнцем?» Звучит странно, но именно такой подход является ключом к реализации нашего эффекта. Чтобы полностью понять принцип, мы откажемся от наших мебельных условностей и соберем абстрактную сцену, как на картинке. —>
#rdclr_frontend #WebGL
Из-за того, что Blitz3D, с которого я начинал знакомство с графикой, не сильно был способен реализовать какие-либо графические эффекты (а связано это было с тем, что он был довольно старым и использовал под капотом Direct3D 7), меня всегда впечатляли приемы, которые использовали «взрослые» игры, например — тени. 👣
Если мы соберем сцену с улицей, она будет казаться неполной и плоской, так как обычно мы привыкли видеть тень от солнца на всех объектах. И как оказалось, тень от солнца является одним из самых простых эффектов, который можно реализовать с помощью шейдеров. Как же оно работает?
На самом деле, чтобы представить и посчитать тени, мы должны подумать немного нестандартно, и представить: «а что бы мы видели, если бы именно мы были солнцем?» Звучит странно, но именно такой подход является ключом к реализации нашего эффекта. Чтобы полностью понять принцип, мы откажемся от наших мебельных условностей и соберем абстрактную сцену, как на картинке. —>
#rdclr_frontend #WebGL
❤5
Разбираем тени / 2 (простой пример работы шейдеров)
☀️ За первый проход с камерой нужно поступить немного по-другому: нам нужно поставить ее не туда, где мы хотим, чтобы она была, а именно туда, откуда «светит» солнце.
Мало того, что мы по-особенному ставим камеру, так еще и рисуем не прямо на экран, а в отдельный буфер, который на самом деле является обычной текстурой. Плюсом ко всему, нам не нужен цвет или освещение, нам нужно просто понять, насколько отрисованный пиксель находится далеко от «солнца» — поэтому нам хватит текстуры только с красным каналом, куда мы и пишем расстояние от камеры до пикселя. Если все сделано правильно, мы получим карту теней, или shadow map.
🌪Второй проход — это как раз стандартная отрисовка нашей сцены, но с небольшой оговоркой.
Теперь, когда мы будем рисовать нашу сцену, мы ставим камеру как нам нужно и рисуем все, но только для каждого пикселя нам нужно вычислить другой алгоритм: мы берем каждый пиксель, опять считаем его удаленность от солнца и сравниваем с той самой картой теней. Пиксель находится дальше от солнца, чем значение в карте теней по этим координатам? Значит, наш пиксель находится в тени, так как есть какой-то объект, который находится к солнцу ближе, чем наш пиксель.
Это очень упрощенное описание алгоритма, но оно позволяет понять общий принцип работы теней в графике. Также почти всегда одной картой теней все не ограничивается, и их рендерят 3 или 4 штуки — каждая из них охватывает площадь больше, чем предыдущая. Это сделано для того, чтобы рядом с игроком качество теней было выше, чем грубо говоря в 100 метрах от камеры. 💨
#rdclr_frontend #WebGL
☀️ За первый проход с камерой нужно поступить немного по-другому: нам нужно поставить ее не туда, где мы хотим, чтобы она была, а именно туда, откуда «светит» солнце.
Мало того, что мы по-особенному ставим камеру, так еще и рисуем не прямо на экран, а в отдельный буфер, который на самом деле является обычной текстурой. Плюсом ко всему, нам не нужен цвет или освещение, нам нужно просто понять, насколько отрисованный пиксель находится далеко от «солнца» — поэтому нам хватит текстуры только с красным каналом, куда мы и пишем расстояние от камеры до пикселя. Если все сделано правильно, мы получим карту теней, или shadow map.
🌪Второй проход — это как раз стандартная отрисовка нашей сцены, но с небольшой оговоркой.
Теперь, когда мы будем рисовать нашу сцену, мы ставим камеру как нам нужно и рисуем все, но только для каждого пикселя нам нужно вычислить другой алгоритм: мы берем каждый пиксель, опять считаем его удаленность от солнца и сравниваем с той самой картой теней. Пиксель находится дальше от солнца, чем значение в карте теней по этим координатам? Значит, наш пиксель находится в тени, так как есть какой-то объект, который находится к солнцу ближе, чем наш пиксель.
Это очень упрощенное описание алгоритма, но оно позволяет понять общий принцип работы теней в графике. Также почти всегда одной картой теней все не ограничивается, и их рендерят 3 или 4 штуки — каждая из них охватывает площадь больше, чем предыдущая. Это сделано для того, чтобы рядом с игроком качество теней было выше, чем грубо говоря в 100 метрах от камеры. 💨
#rdclr_frontend #WebGL
👍2🔥2
Про стадии рендера на почитать
В качестве наглядного пособия сколько всего происходит в графике за один кадр, можно изучить отличнейшую статью про стадии рендера в Grand Theft Auto V. 🚗
Хотя игра уже далеко не новая, в сегодняшних реалиях мало что поменялось в подходах рендеринга сцены с отложенным освещением/затенением и экранных эффектов.
#rdclr_frontend #WebGL #read
В качестве наглядного пособия сколько всего происходит в графике за один кадр, можно изучить отличнейшую статью про стадии рендера в Grand Theft Auto V. 🚗
Хотя игра уже далеко не новая, в сегодняшних реалиях мало что поменялось в подходах рендеринга сцены с отложенным освещением/затенением и экранных эффектов.
#rdclr_frontend #WebGL #read
Adrian Courrèges
GTA V - Graphics Study - Adrian Courrèges
The Grand Theft Auto series has come a long way since
the first opus came out back in 1997.
About 2 years ago, Rockstar released GTA V.
The …
the first opus came out back in 1997.
About 2 years ago, Rockstar released GTA V.
The …
А вот все то же самое, только уже в виде видоса, с разделением по дроуколлам. 🛴
#rdclr_frontend #WebGL #read
#rdclr_frontend #WebGL #read
📌 Итак, Component Driven Development
CDD в разработке интерфейсов — подход, в котором вы сначала создаете систему компонентов, а потом собираете из них UI, как конструктор Lego.
Компонент — независимая строительная единица интерфейса. Сам процесс разработки идет «снизу вверх»: от базовых элементов (компонентов) — к блокам (композиции из компонентов), а затем к страницам, из которых собирается проект.
Какие преимущества дает CDD?
✏️ Качество кода.
Подход предполагает фокусную разработку компонента. Вы концентрируетесь на определенном элементе, описываете его интерфейс, все состояния, пропсы, проверяете все сценарии использования.
✏️Простое тестирование.
Тестировать код на уровне компонента гораздо проще и эффективнее.
✏️Скорость разработки в долгосрочной перспективе.
Да, на начальном этапе разработка займет больше времени, в отличие, например, от Page-based development. Но если проект большой или его нужно масштабировать, это получится сделать гораздо быстрее и безопаснее за счет переиспользования компонентов.
✏️ Простота обучения команды.
Если к работе подключается новый разработчик, он быстрее разберется в коде и вольется в проект.
✏️Удобный рефакторинг.
Внося изменения в одни компоненты, вы не сломаете другие, потому что они изолированы.
В результате вы получаете собранный UI kit с чистым, читабельным кодом. Круто, но это все еще не дотягивает до конструктора Lego. Чего не хватает?
🍹Хороший UI — это результат плотной работы дизайнеров и разработчиков. Чтобы спроектировать такой интерфейс, нам нужно создать мост, который объединит усилия команд дизайна и разработки в единое целое. Этот мост — дизайн-система.
О ней я расскажу завтра. А вы пока подумайте, как начать разработку не с хедера или футера)
#rdclr_frontend #product
CDD в разработке интерфейсов — подход, в котором вы сначала создаете систему компонентов, а потом собираете из них UI, как конструктор Lego.
Компонент — независимая строительная единица интерфейса. Сам процесс разработки идет «снизу вверх»: от базовых элементов (компонентов) — к блокам (композиции из компонентов), а затем к страницам, из которых собирается проект.
Какие преимущества дает CDD?
✏️ Качество кода.
Подход предполагает фокусную разработку компонента. Вы концентрируетесь на определенном элементе, описываете его интерфейс, все состояния, пропсы, проверяете все сценарии использования.
✏️Простое тестирование.
Тестировать код на уровне компонента гораздо проще и эффективнее.
✏️Скорость разработки в долгосрочной перспективе.
Да, на начальном этапе разработка займет больше времени, в отличие, например, от Page-based development. Но если проект большой или его нужно масштабировать, это получится сделать гораздо быстрее и безопаснее за счет переиспользования компонентов.
✏️ Простота обучения команды.
Если к работе подключается новый разработчик, он быстрее разберется в коде и вольется в проект.
✏️Удобный рефакторинг.
Внося изменения в одни компоненты, вы не сломаете другие, потому что они изолированы.
В результате вы получаете собранный UI kit с чистым, читабельным кодом. Круто, но это все еще не дотягивает до конструктора Lego. Чего не хватает?
🍹Хороший UI — это результат плотной работы дизайнеров и разработчиков. Чтобы спроектировать такой интерфейс, нам нужно создать мост, который объединит усилия команд дизайна и разработки в единое целое. Этот мост — дизайн-система.
О ней я расскажу завтра. А вы пока подумайте, как начать разработку не с хедера или футера)
#rdclr_frontend #product
👍14🔥2
Дизайн-система для frontend-разработчика
Как будто что-то на дизайнерском. Но нет.
Дизайн-система — это набор компонентов, правил и паттернов проектирования UI.
Это результат совместной работы дизайнеров и разработчиков, единый источник правды в процессе разработки проекта.
Чем больше проект, тем объемнее его интерфейс, тем сложнее его реализовывать.
Дизайн-система нужна, чтобы упорядочить все элементы интерфейса, снизить количество ошибок (и в коде, и в макетах) и сделать разработку быстрее.
Что должно быть в дизайн-системе:
🌔 набор стилевых правил - цветовая палитра, шрифты, типографика;
🌓 набор компонентов и блоков интерфейса;
🌒 документация — для каждого элемента есть описание интерфейса, свойств и состояний;
🌑 иерархия — компоненты разделены по уровням.
С точки зрения разработки плюсы дизайн-системы очевидны: меньше бардака, меньше ошибок, понятный код, удобство использования. Кроме этого, с помощью нее разработчики и дизайнеры находят общий язык и могут сосредоточиться на решении продуктовых задач, а не их реализации.
Надо понимать, что разработка дизайн-системы — это часть инфраструктуры проекта и на начальном этапе она занимает много времени. Но с ее помощью можно сократить временные и финансовые затраты в долгосрочной перспективе. Например, в продуктовых компаниях или очень больших проектах за разработку дизайн-системы отвечает отдельная команда, потому что там понимают, что это выгодно.
🌪 И еще один момент: дизайн-система — не конечный результат, а живой организм. Она растет и развивается вместе с проектом, поэтому у вас всегда будут задачи по ее поддержке.
Построение системы — навык, который нужно тренировать. Поэтому в следующих постах разберем, как же собрать дизайн-систему для проекта.
#rdclr_frontend #product
Как будто что-то на дизайнерском. Но нет.
Дизайн-система — это набор компонентов, правил и паттернов проектирования UI.
Это результат совместной работы дизайнеров и разработчиков, единый источник правды в процессе разработки проекта.
Чем больше проект, тем объемнее его интерфейс, тем сложнее его реализовывать.
Дизайн-система нужна, чтобы упорядочить все элементы интерфейса, снизить количество ошибок (и в коде, и в макетах) и сделать разработку быстрее.
Что должно быть в дизайн-системе:
🌔 набор стилевых правил - цветовая палитра, шрифты, типографика;
🌓 набор компонентов и блоков интерфейса;
🌒 документация — для каждого элемента есть описание интерфейса, свойств и состояний;
🌑 иерархия — компоненты разделены по уровням.
С точки зрения разработки плюсы дизайн-системы очевидны: меньше бардака, меньше ошибок, понятный код, удобство использования. Кроме этого, с помощью нее разработчики и дизайнеры находят общий язык и могут сосредоточиться на решении продуктовых задач, а не их реализации.
Надо понимать, что разработка дизайн-системы — это часть инфраструктуры проекта и на начальном этапе она занимает много времени. Но с ее помощью можно сократить временные и финансовые затраты в долгосрочной перспективе. Например, в продуктовых компаниях или очень больших проектах за разработку дизайн-системы отвечает отдельная команда, потому что там понимают, что это выгодно.
🌪 И еще один момент: дизайн-система — не конечный результат, а живой организм. Она растет и развивается вместе с проектом, поэтому у вас всегда будут задачи по ее поддержке.
Построение системы — навык, который нужно тренировать. Поэтому в следующих постах разберем, как же собрать дизайн-систему для проекта.
#rdclr_frontend #product
👍8🔥2
Storybook
(ссылка в конце)
Мы выяснили, что дизайн-система — это часть инфраструктуры проекта, как дизайн-макеты и кодовая база. А значит, было бы неплохо иметь инструмент, который позволяет удобно c ней взаимодействовать: разрабатывать, хранить, документировать и пользоваться.
⚙️ Знакомьтесь, это Storybook. Он позволяет делать все то, что я перечислила выше. Его используют Airbnb, Microsoft, Audi, JetBrains, Atlassian и еще много-много компаний. Он дружит с React, Vue, Angular, Svelte и даже Vanilla JS. Подключить его в проект очень просто, а пользоваться реально удобно.
Для каждого компонента, блока или целой страницы создается история — файл с расширением .stories.js (ts, mdx), который и отвечает за отображение вашего элемента. Storybook собирает все эти файлы и формирует библиотеку компонентов. Он разворачивает в браузере интерактивный интерфейс, где можно посмотреть каждый элемент библиотеки изолированно: как он выглядит, как работает, какие у него состояния и пропсы. И да, со всем этим можно взаимодействовать.
⚗️ Я не буду описывать, как подключить Storybook, потому что у него отличная дока и много понятных демок — они расскажут гораздо лучше. Если коротко: скачали npm пакет, запустили из консоли — все. Дальше все зависит от того, насколько хорошо вы опишете компонент. Придерживайтесь правила: одна история — один компонент со всеми его состояниями.
Storybook можно использовать внутри проекта или вынести в отдельный. Если вы только начинаете знакомство с ним, лучше оставьте внутри. Отдельным проектом можно, например, поделиться или собрать из него npm пакет и опубликовать.
Я думаю, вы уже поняли, что Storybook — крутая штука. Так что я предлагаю не медлить, а пойти и установить! Потыкайте и посмотрите, как он работает: не оторваться! Вот вам ссылка https://storybook.js.org/ и увлекательное занятие на выходные. 😜
#rdclr_frontend #product
(ссылка в конце)
Мы выяснили, что дизайн-система — это часть инфраструктуры проекта, как дизайн-макеты и кодовая база. А значит, было бы неплохо иметь инструмент, который позволяет удобно c ней взаимодействовать: разрабатывать, хранить, документировать и пользоваться.
⚙️ Знакомьтесь, это Storybook. Он позволяет делать все то, что я перечислила выше. Его используют Airbnb, Microsoft, Audi, JetBrains, Atlassian и еще много-много компаний. Он дружит с React, Vue, Angular, Svelte и даже Vanilla JS. Подключить его в проект очень просто, а пользоваться реально удобно.
Для каждого компонента, блока или целой страницы создается история — файл с расширением .stories.js (ts, mdx), который и отвечает за отображение вашего элемента. Storybook собирает все эти файлы и формирует библиотеку компонентов. Он разворачивает в браузере интерактивный интерфейс, где можно посмотреть каждый элемент библиотеки изолированно: как он выглядит, как работает, какие у него состояния и пропсы. И да, со всем этим можно взаимодействовать.
⚗️ Я не буду описывать, как подключить Storybook, потому что у него отличная дока и много понятных демок — они расскажут гораздо лучше. Если коротко: скачали npm пакет, запустили из консоли — все. Дальше все зависит от того, насколько хорошо вы опишете компонент. Придерживайтесь правила: одна история — один компонент со всеми его состояниями.
Storybook можно использовать внутри проекта или вынести в отдельный. Если вы только начинаете знакомство с ним, лучше оставьте внутри. Отдельным проектом можно, например, поделиться или собрать из него npm пакет и опубликовать.
Я думаю, вы уже поняли, что Storybook — крутая штука. Так что я предлагаю не медлить, а пойти и установить! Потыкайте и посмотрите, как он работает: не оторваться! Вот вам ссылка https://storybook.js.org/ и увлекательное занятие на выходные. 😜
#rdclr_frontend #product
Storybook
Storybook: Frontend workshop for UI development
Storybook is a frontend workshop for building UI components and pages in isolation. Thousands of teams use it for UI development, testing, and documentation. It's open source and free.
👍7
Оптимизация анимаций
🔥Стартуем с первым материалом в Телеграфе! Написала для вас о настоящей чёрной магии трансформов:
https://telegra.ph/CHyornaya-magiya-transformov-ili-ob-optimizacii-animacij-06-14
Enjoy!
#rdclr_frontend #Vanilla_JS
🔥Стартуем с первым материалом в Телеграфе! Написала для вас о настоящей чёрной магии трансформов:
https://telegra.ph/CHyornaya-magiya-transformov-ili-ob-optimizacii-animacij-06-14
Enjoy!
#rdclr_frontend #Vanilla_JS
Telegraph
Чёрная магия трансформов или об оптимизации анимаций
🤔 Предположим, стоит задача «сделать параллакс». Первая мысль — поменять свойство top при скролле. Тогда получаем примерно такой код: const scroll = () => { percent = window.scrollY / height; squareArray.forEach((square, i) => { square.style.top = (i *…
❤9🔥3