ReactJS *

Учитывая насколько hype-driven является разработка софта в наше время, можно быть уверенным в том что через несколько лет будут существовать новые модные фреймворки для фронтенд разработки. В момент когда фреймворк на базе которого построено приложение выходит из моды — вы вынуждены либо поддерживать устаревшую (legacy) кодовую базу либо стартовать процесс перевода приложения на новый фреймворк.

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

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

Существует довольно популярный сайт https://custom-elements-everywhere.com где показывается как работают веб-компоненты в разных фреймворках. Почти у всех фреймворков там красивый 100% результат, но у React там очень настораживающие 71%.

Многие пользователи смотрят на эту страничку и делают вывод, что React плохо поддерживает не только веб-компоненты, но и DOM API в принципе. Так ли это? Действительно ли все плохо?

Давайте разбираться!

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

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

В этой части статьи я хочу показать, что:

— редьюсеры - это аналог обычных чистых функции для получения нового состояния.

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

— dispatch + action + action creators - это аналог обычных вызовов функций, и разбиение на dispatch, action, action creators является зачастую ненужным и используются не к месту.

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

Мы рассмотрим React компонент, который можно хорошо разобрать. И мы будем шаг за шагом реорганизовывать его до хорошего уровня. Вы увидите большое количество идей, которые повысят вашу скорость написания кода.

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

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

Главный миф о Дэне Абрамове — что он «создал React». Но хотя это и не так, сейчас он имеет самое прямое отношение к фреймворку, так что поговорить с ним про React очень интересно. Обычно Дэна не увидеть на российских конференциях, но нам помог онлайн-формат, и на HolyJS его подробно расспросили Наталия Теплухина (член core team Vue.js) и Наталия Короткова (занимается веб-проектами с 2010 года).

Тут получился не поверхностный разговор о погоде, а обсуждение технической конкретики для тех, кто вдается в детали. Но под конец были и более общие вопросы: когда появится новая документация React, переписанная с нуля? Что не так с Redux? Как Дэн воспринимает холивары о фреймворках? Что он может рассказать о релокации?

Так что, если не осилите все технические детали в первой половине интервью, переходите ко второй, там попроще. Под катом — и видеозапись разговора, и текстовая расшифровка.

Весной 2020 года KTS вместе с командой спецпроектов ВКонтакте придумали концепцию и механику игры к 5-летию Oreo в России.

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

В этой статье мы расскажем про визуальную составляющую (почти)бесконечной башни на TS + React + MobX + react-spring + styled-components и как мы решали задачи отображения и оптимизаций, чтобы добиться максимально плавного игрового взаимодействия.

В этой статье я покажу, как для React-компонентов реализовать один из подходов на основе сущностей и их составляющих. Описываемый подход используется для решения той же проблемы, что HOC и Custom hooks – повторно использовать код между множеством однотипных объектов/функций и разбивать сложные объекты (такие как компоненты в веб-разработке) на более простые составляющие.

Даже если этот подход вам не интересен, как минимум вы увидите, как можно переделать структуру функциональных компоненты и компонентов-классов под свои нужды. Узнаете нестандартные приемы, которые можно использовать при разработке компонентов.
Те, кто пишет компоненты-классы, узнает, как повторно использовать код более эффективным способом, чем HOC, не создавая лишние компоненты-обертки.

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

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

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

Будет рассказано о декораторах, стратегиях, Entity Component, Entity Component System, деревьях, State Machine, частично о хранении хуков в React.

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

Наверное, каждый программист рано или поздно начинает задумываться о качестве своего кода. И, скорее всего, я не ошибусь, если скажу, что добрая половина разработчиков им вечно недовольна. Мне мой код тоже нравился редко: функции, казалось, можно было бы делать и покороче, лишние вложенности было бы неплохо тоже убирать. Было бы здорово писать тесты и документацию, но на них времени не оставалось почти что никогда.

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

Кардинальным образом ситуация изменилась после того, как я прошел курс HowToCode.  В курсе описан системный и, как всё гениальное, простой и красивый подход к разработке, который сводит воедино анализ, проектирование, документацию, тестирование и разработку кода. Весь курс построен на использовании функциональной парадигмы и языка Scheme (диалекта Lisp), тем не менее, рекомендации вполне применимы и для других языков, а для JavaScript и TypeScript, к которым я постарался их адаптировать, так и вообще подходят отлично.

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

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

Сегодня мы исследуем различные методики и рассмотрим все их детали и тонкости. Следует ли использовать useMemo или memoization? Должен ли я хранить данные с помощью useState и context? Когда мы закончим, вы должны быть в состоянии сделать осознанный выбор в отношении кэширования данных. Вы узнаете обо всех тонкостях.

И много анимированных GIF-файлов. Что еще вы можете желать?

Давайте начнем!

Привет хабр!

В одной из предыдущих моих статей “Все ли вы знаете о useCallback?” мы оценивали когда стоит использовать useCallback, а когда это избыточно. Та статья вызвала большой интерес, поэтому было решено сделать похожую статью на тему когда стоит использовать менее популярный хук useMemo, а когда не стоит (данная статья является расшифровкой видео).

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

Проблемы поиска данных всегда отличались особенной сложностью и зачастую нестандартностью в подходах. Сегодня я бы хотел остановиться на одной интересной задаче, которую мне пришлось решать совсем недавно во время разработки платформы Интернета вещей. Впрочем, такая задача, может встретиться и на любом другом проекте, где есть динамическая подгрузка данных по REST API. Будь то подгрузка во время пагинации, или во время скроллинга, или как то иначе…

• Выбор комнаты
• Отправка сообщений
• Удаление сообщений отправителем
• Хранение сообщений в локальной базе данных в формате JSON
• Хранение имени и идентификатора пользователя в локальном хранилище браузера (local storage)
• Отображение количества активных пользователей
• Отображение списка пользователей с онлайн-индикатором

Наш проект Quarkly по-прежнему в открытой бете, мы готовимся к релизу и в хорошем темпе добавляем функционал, который заложен в Roadmap. При этом апдейты апдейтами, а более активно щупать свою аудиторию, да что там щупать – сформировать комьюнити, которое не против таких виртуальных тактильных манипуляций – это большая и важная задача. С ней пока не всё гладко.

– Вот наш проект, он вот для этого и потенциально решает вот такую задачу.
– А есть юзкейсы? Дайте посмотреть.
– Ок, зайдем позже.

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