Обзор моего опыта открытия и перехода на атомарный дизайн в проекте React Native.

Сначала я расскажу о своем опыте, о проекте, примененном в этом сценарии, и о том, почему я был заинтересован во внедрении Atomic Design. Далее я объясню, какие шаги я предпринял для перехода на шаблон атомарного дизайна. Наконец, я расскажу, с какими проблемами я столкнулся при переходе на Atomic Design и что бы я сделал иначе.

Итак, приступим ...

Мой фон

Я разработчик-самоучка, использующий Javascript почти четыре года и React около двух. Только недавно я взял на себя обязательство изучить React Native и попробовать себя в мобильной разработке.

Проэкт

Обсуждаемый проект представляет собой образовательное приложение, призванное помочь изучающим иврит со спряжениями глаголов. Он имеет 3 основные функции и некоторые другие вспомогательные.

Интерфейс этого проекта был запущен с использованием Expo и зависит от таких пакетов, как response-navigation, response-native-gesture-handler, response-native-async-storage и других.

Его основные функции:
1. Поисковая система, которая позволяет пользователю находить полные таблицы спряжения любого глагола на языке, набрав только одну форму (или перевод) этого глагола. в строку поиска.
2. Интерактивная обучающая игра, которая позволяет пользователю практиковать спряжение глаголов, отвечая на вопросы с множественным выбором (перетаскивая), записывая вопросы и задавая вопросы (чтобы определить, какое спряжение принадлежит какое местоимение, напр. он бежал).
3. Письменные уроки, которые предоставляют пользователю образовательный контент, чтобы узнать, как правильно спрягать каждый образец глагола.

Вспомогательные функции включают:
1. Экран быстрого воспроизведения, который может быстро отслеживать, как пользователь отрабатывает данный набор глаголов.
2. Экран настроек, на котором пользователь может управлять своими личными данными и / или языками обучения.

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

Почему атомарный дизайн?

Изначально каталог моего проекта был структурирован так:

Вначале все работало нормально. Я создавал модули с парой операторов импорта из различных частей проекта. Затем я начал создавать все больше и больше компонентов. Все больше и больше экранов. Больше редукторов. Больше государственного управления. Я начал включать больше запросов API, и в них было задействовано больше бизнес-логики. Рано или поздно я решил, что пришло время очистить мой код, и понял, что у меня огромная организационная проблема. Не поймите меня неправильно, код сработал. Он работал без исключений, но если бы другой разработчик пришел и прочитал его, ему потребовалось бы много времени, чтобы найти свой путь. Имена переменных не описывали, модули располагались в неожиданных местах, и я не соблюдал никаких официальных соглашений о регистре. Говоря языком чистого кода, это была катастрофа.
После небольшого исследования того, как структурировать проект React Native, я нашел эту статью об атомарном дизайне. Я немного изменил их учение, чтобы соответствовать моему делу, но после тонны автономной работы (что было огромной ошибкой, хотя я расскажу об этом позже), моя структура папок изменилась с того, что было на картинке выше, на эту:

Иногда миграция была неприятной, но когда все рефакторинги были завершены, это было огромным облегчением. Я считаю, что читаемость этого исходного кода резко возросла. Компоненты теперь можно легко найти, операторы импорта и экспорта стали более краткими, а имена переменных и каталогов стали понятными. Atomic Design обеспечивает более профессиональный вид проекта, помогая разработчику аккуратно организовать модули в аккуратно организованные каталоги.

Испытания

Вот некоторые из проблем, с которыми я столкнулся при переходе на атомарную структуру папок.
1. Выбор компонентов в какой папке. Естественно, можно предположить, что это очевидно, но когда дело доходит до дела, не всегда ясно, должен ли компонент входить в атомы, молекулы или организмы. Используются только собственные компоненты? Это импорт другого атома? У него есть физический интерфейс или это скорее шаблон?
2. Определение того, когда преобразовывать бизнес-логику в модули, а когда сохранять ее в компоненте. Редукторы, естественно, были модульными, но определенные начальные состояния, в которых использовались служебные функции, должны были оставаться в пределах компонента или вызывать требуемые циклы. Вы когда-нибудь слышали о обязательном цикле? Потому что до сих пор я не…

Что бы я сделал по-другому

Я бы поступил иначе. ТЕСТ после изменения чего-либо. Решил провести неделю оффлайн, ничего не тестируя. И в конце концов я за это заплатил. Когда я, наконец, запустил свой код, меня отвлекло множество предупреждений о необходимости цикла, ошибок типа и других исключений, которых я никогда раньше не видел. Только после того, как я прошел через все это, я смог ощутить преимущества атомарного дизайна.

Наконец, я определенно рекомендую этот шаблон для любого из ваших проектов React Native. Спасибо.