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

Меня зовут Женя, я все еще фронтенд-разработчик в команде Quick Experiments inDrive. В этой статье буду делиться своим выводами, а также прикладывать дополнительные ссылки, чтобы познакомить вас с материалом более подробно.

Стейт-менеджеры уже давно стали своеобразным мемом среди разработчиков. Бытует мнение, что фронтедеры только тем и занимаются, что вместо решения действительно важных и актуальных проблем постоянно переписывают проект с одного стейт-менеджера на другой. Благо их количество и поток новых, выходящих в open source, позволяют. 

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

Меня зовут Женя, я все еще фронтенд-разработчик в команде Quick Experiments inDrive. И я тоже не люблю выделяться из толпы, поэтому предлагаю обратить внимание на новое решение от команды Preact — Signals. Во вступительной статье создатели библиотеки заявляют о том, что сегодня создано огромное количество решений по управлению состоянием приложения, но они требуют сложной и долгой интеграции с фреймворком. Это усложняет проектирование, так как нужно постоянно держать в уме особенности стейт-менеджера. Усложняется и разработка, так как нужно тратить много времени и сил на интеграцию стейт-менеджера и библиотеки рендеринга. 

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

Мы используем preact/compat — с его помощью получаем доступ к множеству библиотек экосистемы React, что делает разработку более гибкой, и при этом можем использовать Preact. Но эти же плюсы зачастую оборачиваются в обратную сторону: например, нет единой методологии по проектированию приложений, как, например, в Angular. Кроме того, многообразие библиотек усложняет погружение в проект, а свобода в реализации и проектировании может обернуться захламлением кодовой базы, что пугает разработчиков, особенно новичков. 

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

Для нашей команды эти проблемы также актуальны. Чтобы их решить раз и навсегда, мы обратились к активно развивающейся методологии Feature-Sliced Design (FSD). Ниже я познакомлю с ее главными принципами и с нашим опытом ее использования. Забыл представиться — я Женя, фронтенд-разработчик в команде Quick Experiments inDrive. Расскажу, как мы занимаемся разработкой внутренних стартапов на основе бизнес-гипотез с помощью FSD.