Знаете, однажды в какой-то статье я наткнулся на интересное высказывание, которое гласило, что фронтенд-разработчик может стать последним рубежом, который может предотвратить создание «неюзабельного» UI. И это чертовски меткое и выразительное высказывание, которое отчасти и привело меня к созданию этой статьи про базовые принципы UX, которые не помешало бы иметь на вооружении каждому фронтенд-разработчику.

Дизайн превью: Марина Четвертакова

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

React основан на компонентом подходе. Когда создается компонент, предполагается, что его будут использовать по назначению. Если в проекте есть таблицы значит надо использовать <Table /> (к примеру), формы - значит <Form />. Естественно названия носят абстрактный характер, в каждом проекте они могут иметь разные названия, но суть их одна.

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

Меня зовут Дмитрий Чернов - старший инженер-программист в компании Nord Clan. И мы начинаем.

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

Дизайн превью: Марина Четвертакова

Типичное видение модели распространения события, которое мы привыкли видеть в интернете - это модель всплытия события (bubbling) подобно пузырьку, или погружению (capturing) подобно “камню”.

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

Уверен, вы когда-нибудь задавались вопросом «Что за зверь эта реактивность и как она работает?». Думаю, что настало время закрыть этот вопрос и рассмотреть работу реактивности на примере Vue.

Дизайн превью: Марина Четвертакова

Всем привет! Меня зовут Константин, я Flutter-разработчик в компании Nord Clan.

В данной статье мы с моей коллегой Анной хотели бы поделиться нашим опытом связки Flutter и home widget на платформе iOS.

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

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

Как часто приходится сталкиваться с тем, что начиная проект и развивая его до какого то момента, приходит понимание что код стал запутанным, а чтобы поправить зависимость в одном модуле, приходится править десятки похожих?

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

Есть MVC-приложение на frontend, которое активно расширяется:  создаются новые модели, представления и контроллеры.
Со временем такое приложение начинает напоминать лабиринт из моделей, а баги, живущие в этом лабиринте превращаются в настоящих минотавров. Но все не так плохо, похоже есть нить, которая ведет из этого лабиринта…

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

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

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

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