beeshell: библиотека компонентов React Native с открытым исходным кодом

представлять

beeshell — базовая библиотека компонентов для приложений React Native.Начиная с версии 0.53.3, она предоставляет полный набор готовых высококачественных компонентов, включая компоненты JavaScript (далее — JS) и композитные компоненты ( в том числе Native code), с участием front-end (FE)), iOS, Android с тремя терминалами, с учетом универсальности и настройки, поддерживает пользовательские темы и используется для разработки и обслуживания мобильных приложений корпоративного уровня. Теперь он с открытым исходным кодом на GitHub, адрес:Github.com/ Миссия США / пчела ...

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

характеристика

• Согласованность стиля пользовательского интерфейса и настройка.
• Универсальность. В основном он реализован с использованием JS для обеспечения кроссплатформенной универсальности.
• Настройка. Мы разделяем компоненты на относительно мелкозернистой основе, полагаясь на уровни наследования через наследование и постепенно улучшая функции, предоставляя возможность расширения наследования и индивидуальной настройки на любом уровне.
• Поддержка встроенных функций. Составные компоненты в библиотеке компонентов содержат собственный код и поддерживают собственные функции, такие как выбор изображения и позиционирование.
• Многофункциональный. Не только компоненты, но и базовые инструменты, анимация и спецификации пользовательского интерфейса.
• Полная документация и примеры использования.

В сравнении

Перед открытым исходным кодом мы провели исследование библиотек компонентов, которые были открыты в отрасли.Здесь мы в основном сравниваем преимущества и недостатки пчелиной оболочки и других библиотек компонентов и предоставляем каждому справку по выбору библиотек компонентов. В настоящее время в отрасли существует много библиотек компонентов с открытым исходным кодом.Здесь мы выбираем только библиотеки компонентов с более чем 5000 звезд Github, сравниваем и анализируем их по пяти параметрам: количество компонентов, универсальность, настройка, содержат ли они родные функции и степень полноты документов.

Библиотека компонентов	количество компонентов	общность	Настройка	Включать ли нативную функциональность	Полнота документации
react-native-elements	16	Сильный, предоставляющий набор элементов управления пользовательского интерфейса с единым стилем.	Слабый, может потребоваться переписать для настройки	нет	высоко
NativeBase	28	Сильный, предоставляющий набор элементов управления пользовательского интерфейса с единым стилем.	, поддерживает переменные темы	да	высоко
ant-design-mobile	41	Сильный, предоставляющий набор элементов управления пользовательского интерфейса с единым стилем.	Некоторые из них могут поддерживать индивидуальные требования	да	Низкий
beeshell	25	Сильный, предоставляющий набор элементов управления пользовательского интерфейса с единым стилем.	Сильный, не только поддерживает предметную переменную, но и поддерживает расширение настройки в наследовании	да	высоко

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

Системный дизайн

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

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

каркасный дизайн

За прошедшие годы появление React Native предоставило новую возможность для мобильной разработки. По сравнению с нативной разработкой React Native имеет более высокую эффективность разработки и лучшую производительность, чем HTML5 и Hybrid, поэтому он может выделиться, что также заставляет все больше и больше разработчиков изучать и использовать React Native.

Библиотека компонентов beeshell основана на React Native, взаимодействует с платформами iOS и Android вниз через React Native и предоставляет удобный для разработчиков унифицированный интерфейс вверх, сглаживая различия между платформами и предоставляя сервисную поддержку пользователям для разработки бизнес-функций. Beeshell выступает в роли посредника, обеспечивая тем самым стабильность и простоту использования основных функций мобильных приложений.

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

Принципы дизайна

Прежде чем перейти к детальному проектированию библиотеки компонентов, мы предлагаем несколько принципов проектирования:

• Реализация JS имеет приоритет. Использование JS для реализации функций имеет несколько преимуществ: кроссплатформенная универсальность, более высокая эффективность разработки, более низкие затраты на обучение и использование.
• Наследование и композиция используются гибко. Наследование и композиция являются эффективными методами проектирования для достижения повторного использования функций и повторного использования кода, а также являются основными структурами в шаблонах проектирования. Наследование позволяет подклассам переопределять и переписывать детали реализации родительского класса Реализация родительского класса видна подклассу, что обычно называется «повторным использованием белого ящика», что очень эффективно для настраиваемого расширения компонентов и пчелиной оболочки. - это мощная настройка. Возможность расширения основана на наследовании; композиция - это способ, рекомендованный React. Компоненты React имеют мощную модель композиции. Общий класс и некоторые классы не заботятся о соответствующих деталях их реализации, а детали реализации между они невидимы. Обычно их называют «повторным использованием черного ящика». Beeshell также широко использует комбинацию, объединяя более богатые, мощные и персонализированные функции на основе компонентов общего назначения, что в определенной степени улучшает возможности настройки beeshell.
• Низкая связанность, высокая сплоченность. Компонент пчелиной оболочки по сути является компонентом React. Компоненты React взаимодействуют в основном через реквизиты, которые относятся к связыванию данных. По сравнению с другими методами связывания, такими как связывание контента и связывание управления, связывание данных наименее связано и выигрывает от React. Это естественно для Компоненты пчелиной скорлупы должны иметь низкую связанность, а для достижения высокой связности существуют определенные требования к реализации кодирования компонентов.Мы реализуем интерактивную связность и последовательную связность с относительно высокой степенью связности в связном режиме. Используйте единый источник данных, чтобы каждый элемент работал с одной и той же структурой данных для достижения согласованного взаимодействия. При использовании метода обновления неизменяемых данных выходные данные предыдущей ссылки являются входными данными следующей ссылки, обрабатывая логику подобно конвейеру, который является последовательной связностью.

Дизайн

В целом, JS используется как единый вход, а многоуровневая инкапсуляция скрывает детали реализации, сглаживает различия между JS и Native, платформой iOS и платформой Android и может использоваться «из коробки», снижая стоимость разработки. обучения и использования для пользователей. Частично основываясь на технических характеристиках React Native, он разделен на составную часть JS и составную составную часть.Две части реализуют «слабо связанную» модель разработки, которая позволяет нативной части иметь возможность заменять и изменять и повысить гибкость библиотеки компонентов.

Составная компонентная часть может напрямую отображать интерфейс JS, и при необходимости ее также можно настроить и инкапсулировать в компонентной части JS. Мы делаем все возможное, чтобы обеспечить атомарность и простоту некоторых функций Native, и используем JS для реализации любых требований к настройке унифицированным образом, в первую очередь следуем принципу проектирования реализации JS и обеспечиваем кросс-платформенные общие функции. Далее представлен дизайн части компонента JS и составной части компонента соответственно.

Дизайн части компонента JS

Дизайн программного обеспечения делится на три уровня дизайна: архитектура, дизайн кода и дизайн исполняемого файла. Мы используем нисходящий подход, начиная с архитектуры для проектирования компонентной части JS.

Обычно существует семь стилей архитектуры программного обеспечения: конвейеры и фильтры, объектно-ориентированный, неявный запрос, иерархический, база знаний, интерпретатор и управление процессами.

Компонентная часть JS использует стиль иерархической архитектуры, который разделен на три уровня: базовые инструменты, общие компоненты и компоненты расширения.. Сверху вниз универсальность постепенно ослабевает, настройка постепенно расширяется, а функция постепенно расширяется. , Каждый слой выполняет свои обязанности, принимая во внимание как универсальность, так и настройку.

• Основные инструменты (общие): самая основная и общая часть, включая JS Utils, определения анимации, спецификации пользовательского интерфейса и т. д.
• Общие компоненты (компоненты): Классифицируйте компоненты с похожими функциями и организуйте их в серии. Каждая серия реализуется путем наследования, послойной зависимости и постепенного расширения функций. Эта часть фокусируется на общности и не рассматривает индивидуальную настройку. обеспечить простоту кода. В то же время компоненты разбиваются с большей степенью детализации, что обеспечивает хорошую масштабируемость.
• Компоненты расширения (модули): это наследование, расширение и комбинированное применение общих компонентов.Эта часть ориентирована на настройку для максимального удовлетворения потребностей бизнеса и имеет низкую универсальность.

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

Конструкция составной детали

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

Составная составная часть инкапсулирует интерфейс через JS, обеспечивая кроссплатформенность. Native часть в основном делится на две части: Native Bridge и чистый Native.Bridge представляет собой пакет для React Native и должен быть реализован в библиотеке компонентов; в то время как чисто Native часть может быть реализована, полагаясь на три стороны через Pods/Gradle, эффективно поглощая и используя технологию родного развития накопления.

Реализация библиотеки компонентов

Гарантия кроссплатформенной универсальности

React Native предоставляет несколько встроенных компонентов. Мы можем использовать JS для реализации функций на основе этих встроенных компонентов. Некоторые из этих встроенных компонентов являются общими для разных платформ, например: платформы соответственно.Реализованы, такие как DatePickerIOS и DatePickerAndroid, AlertIOS и ToastAndroid. Конечно, с кроссплатформенными компонентами проблем нет. Мы можем сосредоточиться на разработке бизнес-функций. Проблема в том, что эти не кроссплатформенные компоненты создают большие проблемы для нашей разработки бизнес-функций. Приведем следующие примеры.

Компонент DatePickerIOS для платформы iOS:

Компонент DatePickerAndroid для платформы Android:

Совершенно другие не только функциональные взаимодействия, но и имена классов и методы вызова, что не только не отвечает потребностям бизнеса, но и требует больших затрат на обучение и использование. Похожих компонентов еще много.Как сгладить платформенные различия и добиться кроссплатформенности? Решение, которое мы предлагаем, состоит в том, чтобы сначала использовать JS для реализации функций, что также является принципом разработки нашей библиотеки компонентов.

В ответ на вышеуказанные проблемы мы разработали компонент Datepicker на основе ScrollView, унифицированного имени класса и метода вызова, а также обеспечили кросс-платформенную универсальность.

Компонент Datepicker для платформы iOS:

Компонент Datepicker для платформы Android:

Datepicker использует JS для полной реализации полной функции, но в некоторых случаях нет необходимости реализовывать полную функцию, мы можем предоставить ее через React Native.Platformдля локальной кроссплатформенной обработки, такой как компонент TextInput.

Компонент TextInput для платформы iOS:

Компонент TextInput для платформы Android:

Мы видим, что значки не очищаются на платформе Android.Чтобы сгладить различия платформ и обеспечить большую универсальность, мы разработали компонент ввода для инкапсуляции и оптимизации TextInput, используяPlatformОриентация на платформу Android для обеспечения функции очистки,

Эффект компонента Input на платформе Android:

Короче говоря, beeshell еще больше оптимизировал кроссплатформенную универсальность, следуя принципу приоритета реализации JS и сотрудничая сPlatformAPI позиционирования платформы обеспечивает лучшую гарантию простоты использования и универсальности компонентов.

Индивидуальная поддержка

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

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

Настройка стиля

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

В начале проектирования библиотеки компонентов спецификация пользовательского интерфейса была унифицирована. В соответствии со спецификацией пользовательского интерфейса мы определяем переменные стиля единообразно и помещаем их в базовый инструментальный слой, а именноbeeshell/common/styles/varibles.jsВ файле, в приложениях React Native, переменные стиля на самом деле являются обычными переменными JS, которые можно легко использовать повторно и переписывать. React Native предоставляетStyleSheetСоздавая таблицу стилей и используя идентификаторы для ссылки на стили, вы можете уменьшить частоту создания новых объектов стиля и гибко использовать их при применении переменных стиля в библиотеке компонентов.StyleSheet.createа такжеStyleSheet.flattenчтобы получить идентификатор стиля и объект стиля.

При реализации каждой группы переменные стиля в базовом инструментальном слое вводятся заранее, и вместо определения себя в компоненте используется унифицированный переменный объект, что обеспечивает согласованность стилей пользовательского интерфейса. В то же время beeshell предоставляет API для сброса переменных стиля, что позволяет создавать скины одним щелчком мыши. Мы рекомендуем пользователям beeshell заранее определять переменные стиля при разработке мобильных приложений. С одной стороны, используйте свои собственные переменные стиля для сброса переменных стиля пчелиной оболочки; с другой стороны, при разработке бизнес-функций используйте собственные определенные переменные стиля, чтобы обеспечить согласованность всего пользовательского интерфейса.

Настройка функций

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

Взаимодействие всплывающих окон на мобильном терминале, как правило, проще, чем на ПК.Мы классифицируем компоненты с похожими взаимодействиями, такими как модальные окна, выпадающие меню и информационные подсказки, в модальные серии, которые реализуются по наследству. Кто-то может спросить, зачем использовать наследование вместо композиции? Как упоминалось выше, основной целью композиции является повторное использование кода, а основной целью наследования является расширение. Учитывая, что существует множество возможностей настройки взаимодействия всплывающих окон, для обеспечения лучшей масштабируемости мы выбираем наследование.

Во-первых, давайте посмотрим на визуализацию реализации нескольких компонентов и получим интуитивное представление о серии Modal.

Модальные компоненты:

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

Компонент ConfirmModal:

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

Компонент SlideModal:

Наследовать компонент Modal, переписать анимацию и контейнер всплывающих окон, создать экземпляр объекта типа SlideAnimated во время инициализации, завершить анимацию вытягивания и опускания и поддерживать функцию настройки положения всплывающего окна.

Компонент PageModal:

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

Компонент CheckboxModal:

Компонент CheckboxModal реализован путем объединения компонентов PageModal и Checkbox, сочетает в себе более мощные функции, основанные на компонентах общего назначения, и следует принципам наследования и комбинирования.

В приведенных выше частях у нас уже было интуитивное понимание серии Modal, а затем давайте взглянем на диаграмму классов и наслоение серии Modal:

Анимационная часть реализована в основном инструменте (общий); в общих компонентах (компонентах) модальный компонент агрегирует анимации FadeAnimated, а так как SlideModal и ConfirmModal более распространены, они также реализованы в этой части; CheckboxModal более настраиваемый и классифицируется как компонент расширения (модули). Благодаря такому многоуровневому слою три уровня выполняют свои обязанности, что делает иерархическую структуру библиотеки компонентов более понятной, что не только реализует настройку, но также обеспечивает простоту и удобство обслуживания общих частей.

Комплексное рассмотрение дел

Взаимная рекурсивная обработка асинхронного рендеринга

Поток JS и поток пользовательского интерфейса приложения React Native — это два потока, которые отличаются от реализации совместного использования одного потока в браузере, поэтому мы можем видеть, что все API-интерфейсы, предоставляемые React Native для работы с элементами пользовательского интерфейса, вызываются через функции обратного вызова. .

Воспользовавшись реакцией, нам вообще не нужно управлять элементами пользовательского интерфейса напрямую, но некоторые компоненты требуют сложных операций интерфейса пользовательских интерфейсов, такие как компонент ScrollerPicker, реализованный полностью на JS:

Нам нужен точный расчет контейнера и высоты каждого из элементов, чтобы получить индекс текущего выбранного элемента в модели данных (массив) правильный. Проблемы сейчас: жизненный цикл после завершения рендеринга компонентовcomponentDidMountи не может получить правильную высоту контейнера и использоватьsetTimeoutТакже встанет вопрос о том, как долго устанавливать время задержки. Мы решили использовать рекурсию для решения, как толькоsetTimeoutЕсли нет, выполните его несколько раз.

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

Механизм отказоустойчивости размера пользовательского интерфейса

React Native предоставляет пользователям атрибут стиля для управления стилем элементов, и мы можем вручную установить размеры соответствующих элементов пользовательского интерфейса. Однако на некоторых машинах Android мы устанавливаем размер элемента таким же, какmeasureИнформация о размере, полученная методом, противоречива.После реального тестирования на большом количестве машин Android мы пришли к выводу, что существует ошибка в несколько десятых долей пикселя.

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

Детальное управление компоновкой

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

Абсолютное позиционирование:

Статическое позиционирование:

Пользовательское местоположение

Как эффективно учитывать разные потребности? Мы предлагаем независимый метод проверки.В родительском компоненте с помощью компонента Form мы используем CVD для определения и настройки правил проверки и вывода результатов проверки в единую структуру данных (единый источник данных).На основе этой структуры данных мы информация может отображаться в любое время, в любом месте и в любом стиле.

Давайте сначала представим CVD:

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

CVD делит процесс ввода элемента управления формы на три уровня:

• Коннектор Коннектор преобразует введенную пользователем информацию в требуемый формат данных.
• Validator Checker, проверьте отформатированные данные.
• Зависимость Процессор зависимостей, который обрабатывает зависимости между текущим элементом управления и другими элементами управления.

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

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

Ниже приводится ввод имени компонента ввода в качестве примера для подробного объяснения.Код выглядит следующим образом:

существуетonChangeПолучите пользовательский ввод, позвонитеcvd.flowТогда ты можешьcvd.getStoreПолучить результат:

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

тестовое задание

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

модульный тест

Модульное тестирование относится к проверке и проверке наименьшего тестируемого модуля в программном обеспечении. В эпоху структурного программирования модули модульного тестирования относятся к функциям. Библиотека компонентов пчелиной оболочки полностью использует модульное тестирование, которое выполняется разработчиком компонента. Результаты исследований показывают, что полное регрессионное тестирование требуется всякий раз, когда вносятся изменения, особенно для компонентов, обеспечивающих базовую функциональность, а тестирование программных продуктов на ранних этапах жизненного цикла приводит к максимальной эффективности и гарантии качества. Чем позже обнаружена ошибка, тем дороже обойдется ее исправление, а модульное тестирование — это возможность выявить ошибки на ранней стадии.

Преимущества модульного тестирования заключаются в следующем:

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

Библиотека компонентов пчелиной оболочки использует Jest в качестве инструмента для модульного тестирования с собственными инструментами утверждения и покрытия тестами, что позволяет использовать его «из коробки».

Дизайн тестового примера

Ядром тестового примера являются входные данные. В качестве входных данных мы выберем репрезентативные данные. Существует три основных типа: нормальный ввод, граничный ввод и недопустимый ввод. В библиотеке компонентов представлены следующие.isLeapYearФункция инструмента для иллюстрации, код выглядит следующим образом:

Шутка используетtestфункция для описания тестового примера, в которомtoBeСбоку утверждение.

Функция использует внешние данные, и здесь должен быть нормальный ввод2000а также'2000'Оба являются нормальными входными данными, не все функции имеют граничные входные данные и недопустимые входные данные Здесь для иллюстрации используется пример с этими двумя входными данными Граница входных данных является предельным значением допустимых входных данных, здесь0а такжеInfinityявляется граничным вводом; недопустимый ввод — это данные, выходящие за пределы нормального диапазона значений,'xx'а такжеfalseявляется незаконным вводом. При нормальных обстоятельствах, учитывая три вышеуказанных входа, можно выяснить основные функциональные точки функции. Модульное тестирование и написание кода - это «одно тело и две стороны». Три вышеуказанных входа следует учитывать при кодировании, в противном случае надежность кода будут затронуты.Проблемы возникнут.

Упомянутый выше тест предназначен для функции программы, которая представляет собой так называемый «тест черного ящика». Модульное тестирование также требует разработки тестовых данных с другой точки зрения, то есть разработки тестовых случаев для логической структуры программы, что является так называемым «тестом белого ящика».

или сisLeapYearдля иллюстрации, код выглядит следующим образом:

вот одинif elseЗаявление, если мы предоставим только2000ввод, будет только проверятьifзаявление без проверкиelseутверждение. Хотя в случае достаточного тестирования черного ящика тестирование белого ящика не требуется, но, к сожалению, «достаточно достаточно» — это лишь идеальное состояние, и трудно измерить целостность теста, что является основным дефектом черного ящика. тестирование. Преимущество тестирования "белого ящика" заключается в том, что его легко измерить целостность теста, и они отлично дополняют друг друга. Например, после завершения функционального теста вычисляется покрытие операторов. Если покрытие операторов не завершено, вероятно, вызвано непокрытыми операторами. Соответствующие функциональные точки не проверяются.

Тестирование методом «белого ящика» также является относительно распространенным требованием.Jest имеет встроенный инструмент тестового покрытия, который можно добавить непосредственно в команду.--coverageПараметры могут выводить отчет о покрытии юнит-тестами, результаты следующие:

Видно, что каждая строка кода покрыта на 100%, что в значительной степени обеспечивает стабильность функции.

Автоматизированное тестирование пользовательского интерфейса

Снэпшот-тестирование — очень полезный инструмент, гарантирующий, что пользовательский интерфейс библиотеки компонентов не будет случайно изменен. Типичный процесс тестового примера моментального снимка мобильного приложения заключается в визуализации компонентов пользовательского интерфейса, затем создании снимка экрана и сравнении с эталонным изображением, хранящимся независимо от теста. При использовании Jest для тестирования снимков, когда компонент впервые тестируется в beeshell, в тестовом каталоге будет создана папка снимков, и результаты снимков будут храниться в этой папке. Файл результата моментального снимка называется .js.snap, а его содержимое представляет собой дерево компонентов пользовательского интерфейса в определенном состоянии.

В качестве примера возьмем снэпшот компонента «Кнопка»:

После запуска команды для получения результата снимка:

статический анализ

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

Статический анализ эффективен и быстр, он может найти от 30% до 70% проблем в коде, которые можно проверить за несколько минут, с низкими затратами и большими преимуществами. Beeshell использует SonarQube для статической проверки кода.

SonarQube — это система управления качеством кода с открытым исходным кодом, поддерживающая более 25 языков, которая может быть интегрирована с Eclipse, VSCode и другими инструментами с помощью механизма подключаемых модулей для реализации комплексного автоматического анализа и управления качеством кода.

SonarQube проводит всесторонний анализ кода по параметрам надежности, безопасности, ремонтопригодности, охвата и дублирования и обеспечивает это, устанавливая качество кода Quality Gates.

Обзор результатов анализа библиотеки компонентов beeshell показан на рисунке:

Надежность оценивается как A, самая высокая оценка, что означает отсутствие ошибок:

Безопасность имеет рейтинг A, самый высокий рейтинг, что означает отсутствие уязвимостей:

Охват тестами в среднем выше 70%

Согласованность разработки и использования

Библиотека компонентов пчелиной оболочки загружается и используется в виде пакета npm, после успешной загрузки она будет помещена в каталог node_modules корневого каталога проекта, а затем компоненты пчелиной оболочки будут внедрены в проект путем внедрения модулей для использования.

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

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

Теперь наша проблема заключается в том, как синхронизировать пчелиную оболочку в каталоге node_modules с локальным источником пчелиной оболочки.

npm link

Мы знаем, что мы можем использовать ссылку npm для разработки пакетов npm, принцип следующий:

Суть в том, чтобы использовать символьную ссылку, но после того, как мы установили мягкую ссылку, запуск команды пакета сообщил об ошибке, сообщение об ошибкеExpected path '/xxx/xxx/index.js' to be relative to one of project roots

Наша фронтенд-разработка обычно использует Webpack в качестве инструмента упаковки, в то время как приложения React Native используют Metro, нам нужно проанализировать Metro, чтобы найти проблему.

Webpack vs Metro

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

Анализ показал, что конкретный путь Metro — это путь запуска команды пакета по умолчанию и каталог первого уровня в node_modules, чтобы мы могли найти проблему:

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

Используйте программные ссылки напрямую

С помощью команды ln -s установите прямую ссылку между пакетом пчелиной оболочки и исходным кодом пчелиной оболочки в демонстрационном проекте node_modules:

Этот метод также поддерживает разработку исходного кода нативной части iOS и Android.Обратите внимание, что части Android необходимо вызвать метод getCanonicalPath в settings.gradle, чтобы получить путь после установки программной ссылки.

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

перспективы на будущее

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

В настоящее время Beeshell предоставляет компоненты и базовые инструменты 20+.Основываясь на хорошем опыте проектирования и разработки архитектуры, он обеспечивает нам хорошую основу для постоянного пополнения библиотеки компонентов. При этом за несколько лет разработки приложений React Native у нас накопилось более 50 базовых и бизнес-компонентов, мы разберем и настроим накопившиеся компоненты и перенесем их все на beeshell. Поскольку наши компоненты в основном основаны на наших бизнес-потребностях, но бизнес-сценарии ограничены, что может ограничить разработку пчелиной оболочки, поэтому мы открываем исходный код. Я надеюсь использовать возможности сообщества для постоянного обогащения функций библиотеки компонентов и делать все возможное, чтобы охватить все аспекты функций мобильного приложения Мы приветствуем ваши предложения и поддержку.

Мы запланировали три этапа разработки библиотеки компонентов:

• Первый этап, на котором мы находимся сейчас, включает более 20 компонентов с открытым исходным кодом, в основном предоставляющих базовые функции.
• Второй этап — разобрать компоненты, которые мы накопили при разработке приложений React Native за несколько лет, и open source 50+ компонентов.
• Третий этап заключается в изучении общих функций мобильных приложений, их анализе и систематизации, а затем реализации их в более чем 100 компонентах с открытым исходным кодом.

Связанный с открытым исходным кодом

Git-адрес

beeshell

основной участник

внешний интерфейс:Дракон,Мэн Цянь

Родной:Глубокий,Ян Чао