Истории, которые мы заслужили 🤓
#frontend #storybook
При разработке сложных продуктовых интерфейсов встает вопрос дальнейшего масштабирования и сопровождения кодовой базы веб-сервиса. Со временем количество UI-компонентов растет, наряду с этим возрастает и порог вхождения в проект — его расширение и отладка затрудняются.
Привести мысли и структуру проекта в порядок поможет Storybook 😇
Этот инструмент для разработки пользовательских интерфейсов позволяет реализовывать отдельные части интерфейса изолированно от основного приложения, что упрощает тестирование и позволяет отладить компонент с различными данными. Для интерактивного взаимодействия с визуальными компонентами Storybook предоставляет специальный веб-интерфейс.
Одной из ключевых особенностей Storybook является то, что его можно использовать практически с любым инструментарием, будь то React.js, Vue.js или Angular.
Также существует множество плагинов, которые расширяют его интерфейс и добавляют дополнительные методы для работы с компонентами. В одной из прошлых заметок мы уже писали о плагине, с помощью которого можно описать документацию к UI-компонентам.
Основными объектами взаимодействия в Storybook являются истории. Именно они связывают среду разработки и компоненты. Чтобы Storybook мог отличить обычные файлы от историй, используется именование с префиксом .stories.js. Это правило, как и любое другое, можно поменять, расширив конфигурацию инструмента.
После создания истории она появляется в пользовательском интерфейсе вместе с отрендеренным состоянием компонента. Файлы .stories.js включают в себя ряд историй, где каждая из них — это рендер-функция, в которой отражается состояние компонента. Хорошим тоном считается, если один файл истории описывает один компонент в различных состояниях.
О том, как внедрить Storybook в свой проект, вы можете узнать из документации, соответствующей вашему стеку.
Жми на 🔥, и мы продолжим публикации о развитии окружения разработки UI-компонентов — от простого взаимодействия до E2E-тестирования 😎
#frontend #storybook
При разработке сложных продуктовых интерфейсов встает вопрос дальнейшего масштабирования и сопровождения кодовой базы веб-сервиса. Со временем количество UI-компонентов растет, наряду с этим возрастает и порог вхождения в проект — его расширение и отладка затрудняются.
Привести мысли и структуру проекта в порядок поможет Storybook 😇
Этот инструмент для разработки пользовательских интерфейсов позволяет реализовывать отдельные части интерфейса изолированно от основного приложения, что упрощает тестирование и позволяет отладить компонент с различными данными. Для интерактивного взаимодействия с визуальными компонентами Storybook предоставляет специальный веб-интерфейс.
Одной из ключевых особенностей Storybook является то, что его можно использовать практически с любым инструментарием, будь то React.js, Vue.js или Angular.
Также существует множество плагинов, которые расширяют его интерфейс и добавляют дополнительные методы для работы с компонентами. В одной из прошлых заметок мы уже писали о плагине, с помощью которого можно описать документацию к UI-компонентам.
Основными объектами взаимодействия в Storybook являются истории. Именно они связывают среду разработки и компоненты. Чтобы Storybook мог отличить обычные файлы от историй, используется именование с префиксом .stories.js. Это правило, как и любое другое, можно поменять, расширив конфигурацию инструмента.
После создания истории она появляется в пользовательском интерфейсе вместе с отрендеренным состоянием компонента. Файлы .stories.js включают в себя ряд историй, где каждая из них — это рендер-функция, в которой отражается состояние компонента. Хорошим тоном считается, если один файл истории описывает один компонент в различных состояниях.
О том, как внедрить Storybook в свой проект, вы можете узнать из документации, соответствующей вашему стеку.
Жми на 🔥, и мы продолжим публикации о развитии окружения разработки UI-компонентов — от простого взаимодействия до E2E-тестирования 😎
Расширяемая история
#frontend #storybook
В прошлой заметке мы рассказали, зачем нужен инструмент Storybook и как он помогает нам жить 😁 В свои корпоративные шаблоны мы начали внедрять его на основе оригинальной документации с учетом используемого стека. И конечно, встретились с несколькими сложностями.
Например, при внедрении Storybook в сборки React-приложений стало ясно, что некоторые типы импортируемых файлов ему не знакомы. В базовой конфигурации Webpack для Storybook отсутствовали используемые в приложении лоадеры. В нашем случае это были stylus-loader и css-loader с дополнительным набором опций для конфигурации css-modules.
Большинство схожих проблем вам удастся решить путем расширения базовой конфигурации Storybook. За это отвечает специальное поле
Небольшой пример по расширению конфигурации можно посмотреть здесь.
#frontend #storybook
В прошлой заметке мы рассказали, зачем нужен инструмент Storybook и как он помогает нам жить 😁 В свои корпоративные шаблоны мы начали внедрять его на основе оригинальной документации с учетом используемого стека. И конечно, встретились с несколькими сложностями.
Например, при внедрении Storybook в сборки React-приложений стало ясно, что некоторые типы импортируемых файлов ему не знакомы. В базовой конфигурации Webpack для Storybook отсутствовали используемые в приложении лоадеры. В нашем случае это были stylus-loader и css-loader с дополнительным набором опций для конфигурации css-modules.
Большинство схожих проблем вам удастся решить путем расширения базовой конфигурации Storybook. За это отвечает специальное поле
webpackFinal в файле .storybook/main.js. Важно понимать, что мы расширяем, а не полностью заменяем умолчательную webpack-конфигурацию (хотя и такой вариант возможен 😉). Расширение конфигурации описывается функцией, присвоенной полю webpackFinal. В качестве аргументов она принимает конфигурацию webpack по умолчанию и объект с метаинформацией, необходимой для работы Storybook.Небольшой пример по расширению конфигурации можно посмотреть здесь.
⚡️ Быстрый подбор контраста текста в Chromium
#news #frontend #chrome
В новой версии браузерного движка Chromium 86 появилась возможность быстрого подбора цвета текста для повышения его контрастности.
Теперь не придется терять драгоценное время в попытках подобрать нужное сочетание текста и фона по своим ощущениям: DevTools поможет сделать точный выбор.
https://twitter.com/argyleink/status/1296472539175227400?s=19
#news #frontend #chrome
В новой версии браузерного движка Chromium 86 появилась возможность быстрого подбора цвета текста для повышения его контрастности.
Теперь не придется терять драгоценное время в попытках подобрать нужное сочетание текста и фона по своим ощущениям: DevTools поможет сделать точный выбор.
https://twitter.com/argyleink/status/1296472539175227400?s=19
Twitter
Adam Argyle
in Chromium 86 now: 1-click #accessibility color contrast correction for AA and AAA ratios 🎉 Struggle to fix failing contrast ratios? Tired of the guess and check? @ChromeDevTools has your back. Here's a video of me fixing a few pesky ratio's with the new…
Жучки в моей голове 🐛🐞🐜
#backend #debug #php
Мы не раз писали о способах отладки и профилирования frontend-приложений посредством браузера.
А как же отлаживается backend?🤔 Начинающий php-разработчик предпочитает использовать простые конструкции вывода для отладки данных и структур. Например, такое сочетание крайне часто можно встретить в коде джуниор-разработчика:
Лишь бы такая отладка не дошла до прода 😩
Для полноценной отладки и профилирования кода мы используем Xdebug, который поставляется как php-расширение. Современные IDE, например JB PhpStorm, с легкостью интегрируются с этой библиотекой отладки, как в случае с локальным php-интерпретатором, так и в случае если Xdebug установлен в Docker-контейнере. Наши разработчики применяют специально подготовленное Docker-окружение, и поэтому мы используем второй вариант.
Современные php-фреймворки также предоставляют отладочные инструменты уровня приложения. Например, для профилирования SQL-запросов, которые генерирует ORM.
Удобные отладочные панели есть у фреймворков Yii и Laravel. Если вы не используете каркасы, а разрабатываете приложение на разнородных composer-пакетах или на микрофреймворках, то можно применять, например, PHP Debug Bar.
Важно помнить, что любые средства отладки, будь то отдельные php-расширения либо встроенные в ваш фреймворк компоненты и модули, должны быть отключены в промышленном и тестовом окружении. Их работа регрессивно влияет на производительность приложения, а также через отладочную информацию злоумышленник может получить ценные данные. Инструменты отладки и профилирования должны быть доступны только в процессе разработки веб-приложения.
#backend #debug #php
Мы не раз писали о способах отладки и профилирования frontend-приложений посредством браузера.
А как же отлаживается backend?🤔 Начинающий php-разработчик предпочитает использовать простые конструкции вывода для отладки данных и структур. Например, такое сочетание крайне часто можно встретить в коде джуниор-разработчика:
...
var_dump($someVar); // print_r($someVar);
die();
...
Лишь бы такая отладка не дошла до прода 😩
Для полноценной отладки и профилирования кода мы используем Xdebug, который поставляется как php-расширение. Современные IDE, например JB PhpStorm, с легкостью интегрируются с этой библиотекой отладки, как в случае с локальным php-интерпретатором, так и в случае если Xdebug установлен в Docker-контейнере. Наши разработчики применяют специально подготовленное Docker-окружение, и поэтому мы используем второй вариант.
Современные php-фреймворки также предоставляют отладочные инструменты уровня приложения. Например, для профилирования SQL-запросов, которые генерирует ORM.
Удобные отладочные панели есть у фреймворков Yii и Laravel. Если вы не используете каркасы, а разрабатываете приложение на разнородных composer-пакетах или на микрофреймворках, то можно применять, например, PHP Debug Bar.
Важно помнить, что любые средства отладки, будь то отдельные php-расширения либо встроенные в ваш фреймворк компоненты и модули, должны быть отключены в промышленном и тестовом окружении. Их работа регрессивно влияет на производительность приложения, а также через отладочную информацию злоумышленник может получить ценные данные. Инструменты отладки и профилирования должны быть доступны только в процессе разработки веб-приложения.
Быстро и метко про хороший ООП-код
#useful #backend #php
А вы думаете об архитектуре своего кода? Расскажите нам в комментариях.
Полезное видео от core-разработчика Yii Framework.
https://youtu.be/SKwchYgaJN8
#useful #backend #php
А вы думаете об архитектуре своего кода? Расскажите нам в комментариях.
Полезное видео от core-разработчика Yii Framework.
https://youtu.be/SKwchYgaJN8
Полезные обертки для историй 🤓
#frontend #storybook #react
Продолжаем рассказывать про экосистему инструмента Storybook. В предыдущих заметках мы рассказывали про установку и конфигурацию Storybook. Описанных действий будет достаточно, чтобы начать работать с компонентами дизайн-системы, которые не используют данные из React-контекста.
Однако в крупных проектах может быть реализована глубокая вложенность провайдеров контекста, которые необходимы для работы отдельных библиотек или всего UI.
Например, добавление в Storybook компонента, использующего Redux Store, вызовет исключение. Дело в том, что компоненты подписываются на Store с помощью специального провайдера, который располагается в корне проекта. Чаще всего это основной App-компонент. А поскольку Storybook изолирован от основного приложения, то ему ничего не известно и о провайдерах, используемых в этом приложении.
Решение есть! 🎉 Storybook позволяет реализовывать декораторы для «обертки» истории в рендер-функцию, в которой можно описать применение необходимых провайдеров. Декораторы можно использовать как в отдельно взятой истории, так и глобально — для всех описанных сторис.
Подробнее о том, как использовать библиотеку Redux в историях, можно почитать здесь. Ну а гайд по применению Storybook при разработке React-приложений можно найти тут.
#frontend #storybook #react
Продолжаем рассказывать про экосистему инструмента Storybook. В предыдущих заметках мы рассказывали про установку и конфигурацию Storybook. Описанных действий будет достаточно, чтобы начать работать с компонентами дизайн-системы, которые не используют данные из React-контекста.
Однако в крупных проектах может быть реализована глубокая вложенность провайдеров контекста, которые необходимы для работы отдельных библиотек или всего UI.
Например, добавление в Storybook компонента, использующего Redux Store, вызовет исключение. Дело в том, что компоненты подписываются на Store с помощью специального провайдера, который располагается в корне проекта. Чаще всего это основной App-компонент. А поскольку Storybook изолирован от основного приложения, то ему ничего не известно и о провайдерах, используемых в этом приложении.
Решение есть! 🎉 Storybook позволяет реализовывать декораторы для «обертки» истории в рендер-функцию, в которой можно описать применение необходимых провайдеров. Декораторы можно использовать как в отдельно взятой истории, так и глобально — для всех описанных сторис.
Подробнее о том, как использовать библиотеку Redux в историях, можно почитать здесь. Ну а гайд по применению Storybook при разработке React-приложений можно найти тут.
Готовим новые доки 📄
#frontend #storybook #react
С момента выхода этой заметки появилась новая мажорная версия Storybook 6.0, а вместе с ней плагин Notes, который мы использовали для документирования UI, безвозвратно устарел и перестал поддерживаться 👨🦳
Далее мы расскажем про работу с еще одним расширением для документирования Docs, которое полностью покрывает функционал предшественника, при этом увеличивая его возможности.
К сожалению, интерфейсы расширений не совместимы друг с другом, а значит, просто заменить Notes на Docs не выйдет. Поскольку оба аддона могут сосуществовать в рамках одного Storybook, можно постепенно переходить на новое расширение, переписывая документацию частями.
После подключения расширения в каждой истории появляется вкладка Docs, которая содержит соответствующую документацию по тому или иному компоненту.
По умолчанию за генерацию документации отвечает DocsPage-компонент. Документация строится на основе метаинформации о текущем сторис.
Для расширения возможностей документирования можно заменить стандартный DocsPage-компонент на кастомный, построенный на нужных нам Dock Blocks. Список доступных блоков c описанием можно найти здесь.
Аддон Docs позволяет использовать MDX-разметку, благодаря чему можно описывать компоненты с помощью Markdown-разметки и JSX для рендеринга их состояния по аналогии с нативным API Storybook. MDX-формат также можно использовать для написания только Markdown-разметки без вывода компонента. В таком случае Canvas будет повторять вкладку Docs. Подробнее о данной фиче можно узнать здесь.
Плагин Docs устроен сложнее своих аналогов, в том числе и устаревшего Notes. При этом обладает большими функциональными возможностями для описания UI-компонентов.
#frontend #storybook #react
С момента выхода этой заметки появилась новая мажорная версия Storybook 6.0, а вместе с ней плагин Notes, который мы использовали для документирования UI, безвозвратно устарел и перестал поддерживаться 👨🦳
Далее мы расскажем про работу с еще одним расширением для документирования Docs, которое полностью покрывает функционал предшественника, при этом увеличивая его возможности.
К сожалению, интерфейсы расширений не совместимы друг с другом, а значит, просто заменить Notes на Docs не выйдет. Поскольку оба аддона могут сосуществовать в рамках одного Storybook, можно постепенно переходить на новое расширение, переписывая документацию частями.
После подключения расширения в каждой истории появляется вкладка Docs, которая содержит соответствующую документацию по тому или иному компоненту.
По умолчанию за генерацию документации отвечает DocsPage-компонент. Документация строится на основе метаинформации о текущем сторис.
Для расширения возможностей документирования можно заменить стандартный DocsPage-компонент на кастомный, построенный на нужных нам Dock Blocks. Список доступных блоков c описанием можно найти здесь.
Аддон Docs позволяет использовать MDX-разметку, благодаря чему можно описывать компоненты с помощью Markdown-разметки и JSX для рендеринга их состояния по аналогии с нативным API Storybook. MDX-формат также можно использовать для написания только Markdown-разметки без вывода компонента. В таком случае Canvas будет повторять вкладку Docs. Подробнее о данной фиче можно узнать здесь.
Плагин Docs устроен сложнее своих аналогов, в том числе и устаревшего Notes. При этом обладает большими функциональными возможностями для описания UI-компонентов.
⚡️Вкладывай валидно
#frontend #html
Рекомендуем удобный инструмент для проверки совместимости контентных моделей элементов. Теперь не нужно искать и пытаться интерпретировать информацию официальных источников. Все понятно и user-friendly 😎
#frontend #html
Рекомендуем удобный инструмент для проверки совместимости контентных моделей элементов. Теперь не нужно искать и пытаться интерпретировать информацию официальных источников. Все понятно и user-friendly 😎
«Вредные советы» для оопэшника 😈
#advices #patterns #backend #frontend #mobile
«Я знаю KISS, DRY, YAGNI, GRASP, SOLID, DDD и много других страшных слов».
Начинающему разработчику всегда сложно разобраться в паттернах проектирования, методологиях и концептуальных подходах, таких как, например, MVC, MVVM или MVP. Многочисленные материалы и статьи по темам не дают конкретики по реализации, а главное, по применению обозначенных подходов на практике. Тогда разработчик начинает знакомиться с этими методологиями в рамках выбранного фреймворка, работая с уже реализованными абстракциями, порой не понимая даже, зачем они нужны. По принципу «так сказал фреймворк».
Как только сложность разрабатываемого функционала начинает возрастать и выходит за рамки туториалов по используемому каркасу, получается примерно такой код, состоящий всего из трех файлов, но имеющий объем более 500 строк, и ощущение того, что что-то пошло не так 🤔
Для развития архитектурного мышления одного лишь опыта недостаточно. Можно много лет заниматься разработкой ПО, но не развиваться как программист. Писать плохой, но рабочий код, при этом расходуя огромное количество времени на его сопровождение и частичное переписывание для расширения функционала.
Дадим пару советов, как стать на путь истинного оопэшника:
— Экспериментируй. Важно постоянно экспериментировать и внедрять в свой процесс разработки что-то новое. Например, можно начать с простых декомпозиций монолитного кода на отдельные, независимые друг от друга компоненты, обладающие единой ответственностью. Важно соблюдать принцип необходимости — избегать переабстрагирования и неверного применения тех или иных паттернов дизайна архитектуры.
— Много читай. Начни с классической и концептуальной литературы, не останавливайся на понимании каких-то гайдов к инструментам и библиотекам. Например, начни с настольной книги для каждого ООП-программиста — Gang Of Four.
— Общайся со «старшими». Когда ты работаешь в большой экосистеме разработчиков, тебя развивает окружение и более опытные наставники. Если ты лишен такой экосистемы, например ты фрилансер, то старайся посещать релевантные конференции, митапы и тусовки своего города и доступных тебе локаций. Старайся общаться, принимать и передавать опыт. Поставь себе цель дорасти до спикера, а не оставаться в слушателях.
#advices #patterns #backend #frontend #mobile
«Я знаю KISS, DRY, YAGNI, GRASP, SOLID, DDD и много других страшных слов».
Начинающему разработчику всегда сложно разобраться в паттернах проектирования, методологиях и концептуальных подходах, таких как, например, MVC, MVVM или MVP. Многочисленные материалы и статьи по темам не дают конкретики по реализации, а главное, по применению обозначенных подходов на практике. Тогда разработчик начинает знакомиться с этими методологиями в рамках выбранного фреймворка, работая с уже реализованными абстракциями, порой не понимая даже, зачем они нужны. По принципу «так сказал фреймворк».
Как только сложность разрабатываемого функционала начинает возрастать и выходит за рамки туториалов по используемому каркасу, получается примерно такой код, состоящий всего из трех файлов, но имеющий объем более 500 строк, и ощущение того, что что-то пошло не так 🤔
Для развития архитектурного мышления одного лишь опыта недостаточно. Можно много лет заниматься разработкой ПО, но не развиваться как программист. Писать плохой, но рабочий код, при этом расходуя огромное количество времени на его сопровождение и частичное переписывание для расширения функционала.
Дадим пару советов, как стать на путь истинного оопэшника:
— Экспериментируй. Важно постоянно экспериментировать и внедрять в свой процесс разработки что-то новое. Например, можно начать с простых декомпозиций монолитного кода на отдельные, независимые друг от друга компоненты, обладающие единой ответственностью. Важно соблюдать принцип необходимости — избегать переабстрагирования и неверного применения тех или иных паттернов дизайна архитектуры.
— Много читай. Начни с классической и концептуальной литературы, не останавливайся на понимании каких-то гайдов к инструментам и библиотекам. Например, начни с настольной книги для каждого ООП-программиста — Gang Of Four.
— Общайся со «старшими». Когда ты работаешь в большой экосистеме разработчиков, тебя развивает окружение и более опытные наставники. Если ты лишен такой экосистемы, например ты фрилансер, то старайся посещать релевантные конференции, митапы и тусовки своего города и доступных тебе локаций. Старайся общаться, принимать и передавать опыт. Поставь себе цель дорасти до спикера, а не оставаться в слушателях.
🎧 Слушай, запоминай и применяй
#news #backend #frontend
Как с пользой провести время в поездке по маршруту «дом — работа — дом» или в ожидании своей очереди где-либо?
Наш тимлид backend-разработки слушает сам и вам рекомендует следующие подкасты:
— «Подлодка»;
— «Запуск завтра»;
— «Веб-стандарты»;
— «Девшахта»;
— «Пятиминутка React»;
— «Пятиминутка PHP».
#news #backend #frontend
Как с пользой провести время в поездке по маршруту «дом — работа — дом» или в ожидании своей очереди где-либо?
Наш тимлид backend-разработки слушает сам и вам рекомендует следующие подкасты:
— «Подлодка»;
— «Запуск завтра»;
— «Веб-стандарты»;
— «Девшахта»;
— «Пятиминутка React»;
— «Пятиминутка PHP».
Микрозаметка про микрооптимизацию PHP 7+
#backend #php
Практическое применение микрооптимизаций в PHP 7+ скоро полностью войдет в признаки хорошего тона при написании кода. Так, некоторые нативные функции PHP лучше вызывать явно с префиксом корневого пространства имен
Например, в известном инструменте анализа кода PHP Coding Standards Fixer можно встретить вот такой issue с достаточно большой историей обсуждения, вплоть до недавнего времени. Кстати, запрос на фичу поступил от одного из основных контрибьюторов фреймворка Symfony, в котором эта микрооптимизация уже применяется достаточно давно.
#backend #php
Практическое применение микрооптимизаций в PHP 7+ скоро полностью войдет в признаки хорошего тона при написании кода. Так, некоторые нативные функции PHP лучше вызывать явно с префиксом корневого пространства имен
\. Это гарантирует их более быстрое исполнение через интерпретацию соответствующих opcodes.
Например, в известном инструменте анализа кода PHP Coding Standards Fixer можно встретить вот такой issue с достаточно большой историей обсуждения, вплоть до недавнего времени. Кстати, запрос на фичу поступил от одного из основных контрибьюторов фреймворка Symfony, в котором эта микрооптимизация уже применяется достаточно давно.
Принципы работы веб на пальцах
#backend #frontend #qa #mobile
Собеседуя начинающих технических специалистов, мы часто задаем вопрос о том, что происходит после ввода URL в адресной строке браузера и нажатия кнопки Enter.
Иногда мы получаем неоднозначные ответы 😂
Для того чтобы быстро разобраться с общим принципом работы веб-сервисов, загляните по ссылке ниже 👇
З.Ы. Golang тут ни при чем 😎
#backend #frontend #qa #mobile
Собеседуя начинающих технических специалистов, мы часто задаем вопрос о том, что происходит после ввода URL в адресной строке браузера и нажатия кнопки Enter.
Иногда мы получаем неоднозначные ответы 😂
Для того чтобы быстро разобраться с общим принципом работы веб-сервисов, загляните по ссылке ниже 👇
З.Ы. Golang тут ни при чем 😎
Реактивные формы 🚀
#frontend #react
Работая с библиотекой React, важно отслеживать производительность интерфейса и его компонентов. Самый простой способ оптимизации производительности — уменьшение количества повторных рендерингов компонентов при пользовательском взаимодействии с ними.
Рассмотрим пример простого, но часто достаточно нагруженного компонента — формы ввода данных. Подобный код можно встретить как в туториалах, так и в реальных проектах. Поле, значение, state… — на первый взгляд все так 🤔
Но, используя state, мы заставляем ререндериться всю форму при каждом изменении значения поля input. Если форма обладает большим количеством разнородных полей, например, служит для фильтрации товаров в разделе интернет-магазина, то большое количество ее ререндеров негативно скажется на общей производительности интерфейса.
Именно смена состояния компонента вызывает его дополнительные перерисовки, которые могут являться избыточными. Вместо того чтобы перезаписывать state, используйте ref-ссылку 🥳
После внимательного просмотра нашей формы становится очевидно, что состояние поля ввода input необходимо только перед ее непосредственной отправкой на сервер. Тогда можно получить ссылку на DOM-элемент input и передать его значение в обработчике отправки формы. Пример оптимизированного кода с использованием ref смотрите здесь.
Такой подход в лоб может применяться для простых компонентов. Для более комплексных решений мы рекомендуем рассмотреть библиотеку react-hook-form. Под капотом она использует схожую с нашим примером механику и применяет ref-ссылки для получения доступа к значению поля.
#frontend #react
Работая с библиотекой React, важно отслеживать производительность интерфейса и его компонентов. Самый простой способ оптимизации производительности — уменьшение количества повторных рендерингов компонентов при пользовательском взаимодействии с ними.
Рассмотрим пример простого, но часто достаточно нагруженного компонента — формы ввода данных. Подобный код можно встретить как в туториалах, так и в реальных проектах. Поле, значение, state… — на первый взгляд все так 🤔
Но, используя state, мы заставляем ререндериться всю форму при каждом изменении значения поля input. Если форма обладает большим количеством разнородных полей, например, служит для фильтрации товаров в разделе интернет-магазина, то большое количество ее ререндеров негативно скажется на общей производительности интерфейса.
Именно смена состояния компонента вызывает его дополнительные перерисовки, которые могут являться избыточными. Вместо того чтобы перезаписывать state, используйте ref-ссылку 🥳
После внимательного просмотра нашей формы становится очевидно, что состояние поля ввода input необходимо только перед ее непосредственной отправкой на сервер. Тогда можно получить ссылку на DOM-элемент input и передать его значение в обработчике отправки формы. Пример оптимизированного кода с использованием ref смотрите здесь.
Такой подход в лоб может применяться для простых компонентов. Для более комплексных решений мы рекомендуем рассмотреть библиотеку react-hook-form. Под капотом она использует схожую с нашим примером механику и применяет ref-ссылки для получения доступа к значению поля.
Становись иосником быстро и бесплатно
#ios #mobile_dev
Подборка бесплатных, а главное, полезных образовательных ресурсов, которые помогут постигнуть азы iOS-разработки:
— разработка первого приложения по стандартам Apple на UI Kit;
— гайд по Auto Layout;
— документация Apple;
— бесплатный курс от Стэнфордского университета по UI Kit;
— в дополнение к 👆 отсюда берем 8, 12, 13 темы;
— разъяснение некоторых тем прошлых курсов на русском языке;
— новый курс от Стэнфордского университета по использованию Swift UI;
— статья для обучения RxSwift.
#ios #mobile_dev
Подборка бесплатных, а главное, полезных образовательных ресурсов, которые помогут постигнуть азы iOS-разработки:
— разработка первого приложения по стандартам Apple на UI Kit;
— гайд по Auto Layout;
— документация Apple;
— бесплатный курс от Стэнфордского университета по UI Kit;
— в дополнение к 👆 отсюда берем 8, 12, 13 темы;
— разъяснение некоторых тем прошлых курсов на русском языке;
— новый курс от Стэнфордского университета по использованию Swift UI;
— статья для обучения RxSwift.
Apple Developer Documentation
Introducing SwiftUI | Apple Developer Documentation
SwiftUI is a modern way to declare user interfaces for any Apple platform. Create beautiful, dynamic apps faster than ever before.
Который час, не подскажете?
#mobile_dev #ios #swift
Множество мобильных приложений в процессе своего жизненного цикла оперирует временными интервалами, метками времени и его текущим значением. Например, для контроля подписок пользователя на сервисы или услуги, отслеживания времени доставки еды или поездки на такси.
Стандартные методы Swift позволяют получать системную дату и время iOS-устройства. Такой подход считается весьма ненадежным, и его применение не рекомендуется: время пользовательского устройства легко изменить с помощью системных настроек ОС. Рассмотрим альтернативные способы получения даты и времени, а также их достоинства и недостатки.
С помощью GPS 🛰 Если работа с GPS-модулем устройства доступна, то существует возможность запросить дату и время для текущего региона с помощью объекта
Хитрость с UserDefaults. Это неоднозначное решение позволяет вычислять интервалы времени на основе сохранения времени первого запуска приложения в хранилище UserDefaults и дальнейшего отслеживания и фиксации временных интервалов в процессе работы приложения. Минус очевиден — все теряет смысл, если приложение удалить, а затем установить повторно 😭
NTPD. Весьма стабильный и надежный способ, если исключить возникновение сетевых проблем. Из популярных библиотек есть TrueTime и Kronos.
NTS. Cервис Cloudflare Secure Time Service, например, предоставляет возможность получения даты и времени посредством протокола NTS, обеспечивающего дополнительное шифрование для NTP.
С помощью backend-сервера. Если приложение взаимодействует с backend-сервером, например, по RESTful API и разработчики серверной логики — ваши близкие друзья или вы вообще одна команда, то попросите сделать для вас еще один REST-метод, возвращающий дату и время в нужном вам формате 😎
#mobile_dev #ios #swift
Множество мобильных приложений в процессе своего жизненного цикла оперирует временными интервалами, метками времени и его текущим значением. Например, для контроля подписок пользователя на сервисы или услуги, отслеживания времени доставки еды или поездки на такси.
Стандартные методы Swift позволяют получать системную дату и время iOS-устройства. Такой подход считается весьма ненадежным, и его применение не рекомендуется: время пользовательского устройства легко изменить с помощью системных настроек ОС. Рассмотрим альтернативные способы получения даты и времени, а также их достоинства и недостатки.
С помощью GPS 🛰 Если работа с GPS-модулем устройства доступна, то существует возможность запросить дату и время для текущего региона с помощью объекта
CLLocation фреймворка CoreLocation.Хитрость с UserDefaults. Это неоднозначное решение позволяет вычислять интервалы времени на основе сохранения времени первого запуска приложения в хранилище UserDefaults и дальнейшего отслеживания и фиксации временных интервалов в процессе работы приложения. Минус очевиден — все теряет смысл, если приложение удалить, а затем установить повторно 😭
NTPD. Весьма стабильный и надежный способ, если исключить возникновение сетевых проблем. Из популярных библиотек есть TrueTime и Kronos.
NTS. Cервис Cloudflare Secure Time Service, например, предоставляет возможность получения даты и времени посредством протокола NTS, обеспечивающего дополнительное шифрование для NTP.
С помощью backend-сервера. Если приложение взаимодействует с backend-сервером, например, по RESTful API и разработчики серверной логики — ваши близкие друзья или вы вообще одна команда, то попросите сделать для вас еще один REST-метод, возвращающий дату и время в нужном вам формате 😎
Apple Developer Documentation
Core Location | Apple Developer Documentation
Obtain the geographic location and orientation of a device.
Низкая связанность бывает разной
#backend #frontend #grasp
Современная разработка движется в сторону минимизации зависимостей внутри программного продукта. Сейчас модно использовать микросервисы и распиливать свои монолиты на части.
В разработке мы используем различные архитектурные паттерны и далеко не всегда микросервисную архитектуру. Отдельного внимания заслуживает и модульный монолитный подход с организацией anticorruption layer для независимости каждого из модулей общей системы.
#backend #frontend #grasp
Современная разработка движется в сторону минимизации зависимостей внутри программного продукта. Сейчас модно использовать микросервисы и распиливать свои монолиты на части.
В разработке мы используем различные архитектурные паттерны и далеко не всегда микросервисную архитектуру. Отдельного внимания заслуживает и модульный монолитный подход с организацией anticorruption layer для независимости каждого из модулей общей системы.
Отправка почты кабанчику
#backend #debug #php
При разработке и внедрении веб-сервисов мы постоянно используем нотификацию пользователей посредством email-уведомлений. Регистрация, восстановление забытого пароля, маркетинговые акции — все эти события влекут за собой доставку контента пользователю через почту в виде текстовых или html-писем.
До недавнего времени на этапе отладки работы механизмов email-нотификации мы отправляли генерируемые приложением письма в файл, тем самым эмулируя отправку реального письма.
Современные фреймворки в debug-режиме позволяют конфигурировать свои компоненты-мейлеры для мнимой отправки писем в файлы. Так, Yii Mailer имеет параметр конфигурации useFileTransport, а Laravel позволяет указывать драйвер отправки.
Для себя мы нашли более удобный способ эмуляции отправки и просмотра email-уведомлений — MailHog. Причем для фреймворка такой сервис настраивается и представляется абсолютно так же, как и реальный внешний SMTP-сервер, правда, без шифрования.
Этот сервис состоит из двух основных частей — SMTP-сервера и HTTP-приложения для просмотра и управления полученными от клиентов письмами. При этом реализовано несколько режимов хранения писем — в оперативной памяти и в файловой системе. Приятным дополнением ко всему является возможность поставки сервиса в окружение Docker и Docker Compose, а значит, интеграция и внедрение в окружение наших разработчиков.
#backend #debug #php
При разработке и внедрении веб-сервисов мы постоянно используем нотификацию пользователей посредством email-уведомлений. Регистрация, восстановление забытого пароля, маркетинговые акции — все эти события влекут за собой доставку контента пользователю через почту в виде текстовых или html-писем.
До недавнего времени на этапе отладки работы механизмов email-нотификации мы отправляли генерируемые приложением письма в файл, тем самым эмулируя отправку реального письма.
Современные фреймворки в debug-режиме позволяют конфигурировать свои компоненты-мейлеры для мнимой отправки писем в файлы. Так, Yii Mailer имеет параметр конфигурации useFileTransport, а Laravel позволяет указывать драйвер отправки.
Для себя мы нашли более удобный способ эмуляции отправки и просмотра email-уведомлений — MailHog. Причем для фреймворка такой сервис настраивается и представляется абсолютно так же, как и реальный внешний SMTP-сервер, правда, без шифрования.
Этот сервис состоит из двух основных частей — SMTP-сервера и HTTP-приложения для просмотра и управления полученными от клиентов письмами. При этом реализовано несколько режимов хранения писем — в оперативной памяти и в файловой системе. Приятным дополнением ко всему является возможность поставки сервиса в окружение Docker и Docker Compose, а значит, интеграция и внедрение в окружение наших разработчиков.
Yii Framework
Mailer, yii\swiftmailer\Mailer
Ура[?]! Мы выбрали микросервисы
#backend #architecture
Выбрав для проекта микросервисную архитектуру, вы начинаете задаваться уймой вопросов, связанных со спецификой парадигмы.
Например, как выделить атомарные микросервисы на определенном уровне абстракции. Или каким образом быстро организовать внутреннее взаимодействие между микросервисами на основе gRPC.
Пожалуй, самая важная проблема, которая может решаться на протяжении всего жизненного цикла проекта, — обеспечение консистентности данных. На эту тему мы подобрали несколько интересных докладов, прозвучавших на конференциях Highload++:
— «Целостность данных в микросервисной архитектуре»;
— «Event-Driven Architecture в контексте микросервисов: основные паттерны».
#backend #architecture
Выбрав для проекта микросервисную архитектуру, вы начинаете задаваться уймой вопросов, связанных со спецификой парадигмы.
Например, как выделить атомарные микросервисы на определенном уровне абстракции. Или каким образом быстро организовать внутреннее взаимодействие между микросервисами на основе gRPC.
Пожалуй, самая важная проблема, которая может решаться на протяжении всего жизненного цикла проекта, — обеспечение консистентности данных. На эту тему мы подобрали несколько интересных докладов, прозвучавших на конференциях Highload++:
— «Целостность данных в микросервисной архитектуре»;
— «Event-Driven Architecture в контексте микросервисов: основные паттерны».
Не ORM единым
#orm #dbms #doctrine #activerecord #php
Для абстрагирования работы с БД современные фреймворки используют Persistence Layer, где обычно реализуется паттерн Active Record или применяется ORM.
В результате на уровне приложения мы работаем с map-объектами, которые предоставляют удобный API для безопасного (насколько это возможно) манипулирования данными. Такое удобство может негативно сказываться на общей производительности приложения, особенно при сложных выборка зависимых данных.
Одним из решений проблем производительности является внедрение подхода CQRS. Здесь работа по чтению и записи данных разделяется на отдельные методы-обработчики, но от автоматического мапинга данных придется отказаться в пользу plain-text-запросов на выборку данных.
Разобраться с таким подходом новичку поможет доклад ниже 👇
#orm #dbms #doctrine #activerecord #php
Для абстрагирования работы с БД современные фреймворки используют Persistence Layer, где обычно реализуется паттерн Active Record или применяется ORM.
В результате на уровне приложения мы работаем с map-объектами, которые предоставляют удобный API для безопасного (насколько это возможно) манипулирования данными. Такое удобство может негативно сказываться на общей производительности приложения, особенно при сложных выборка зависимых данных.
Одним из решений проблем производительности является внедрение подхода CQRS. Здесь работа по чтению и записи данных разделяется на отдельные методы-обработчики, но от автоматического мапинга данных придется отказаться в пользу plain-text-запросов на выборку данных.
Разобраться с таким подходом новичку поможет доклад ниже 👇
Минутка PR
#chulakov #release
Много лет мы известны в профессиональном сообществе как дизайн-студия № 1 в России. Наша команда активно реализовывает масштабные и востребованные веб-сервисы для крупнейших банков и телекомов. Мы покоряем рейтинги, получаем награды, но продолжаем оставаться в сознании окружающих представителями исключительно мира дизайна.
На сегодняшний день, помимо дизайна и UX/UI-экспертизы, Студия развивает профессиональное сообщество технических специалистов: веб- и мобильных разработчиков, QA- и DevOps-инженеров, технических руководителей команд и архитекторов ПО.
На полностью обновленном сайте Студии Олега Чулакова мы пересмотрели подход к презентации проектов, показали свои текущие знания, навыки и компетенции.
Теперь каждый человек, которого интересует что угодно в цифровой сфере, от консалтинга до сложной разработки, должен знать, что digital — это мы 😎 И новый сайт прекрасно это отражает.
Переходите по ссылке и убедитесь сами 👇
#chulakov #release
Много лет мы известны в профессиональном сообществе как дизайн-студия № 1 в России. Наша команда активно реализовывает масштабные и востребованные веб-сервисы для крупнейших банков и телекомов. Мы покоряем рейтинги, получаем награды, но продолжаем оставаться в сознании окружающих представителями исключительно мира дизайна.
На сегодняшний день, помимо дизайна и UX/UI-экспертизы, Студия развивает профессиональное сообщество технических специалистов: веб- и мобильных разработчиков, QA- и DevOps-инженеров, технических руководителей команд и архитекторов ПО.
На полностью обновленном сайте Студии Олега Чулакова мы пересмотрели подход к презентации проектов, показали свои текущие знания, навыки и компетенции.
Теперь каждый человек, которого интересует что угодно в цифровой сфере, от консалтинга до сложной разработки, должен знать, что digital — это мы 😎 И новый сайт прекрасно это отражает.
Переходите по ссылке и убедитесь сами 👇