Здравствуйте, давно не виделись. У меня не было времени обобщить и записать свой опыт или практику в течение этого периода времени после смены работы. Наконец-то мне удалось выжать немного времени. Сегодня я хочу записать недавний процесс проектирования и разработки компонентов.Средой разработки этого компонента является апплет, но я думаю, что это мышление универсально~
Эта статья может содержать:
- Введение в требования
- Объединение битовых операций с компонентами формы
- Резюме проекта компонента
Введение в требования
Нам, наверное, нужно заполнить такую форму компонента ↓↓
По рисунку можно примерно судить, что мы должны разделить этот компонент на две части, одна — область опций вкладки, а другая — область дополнительных опций внизу.
Зачем нам нужно разделяться?
-
Основная причина в самом проекте, раньше были вкладки компонентов, и мы можем напрямую ссылаться на них.
-
Конечно, даже если в нашем собственном проекте нет этого компонента, я также рекомендую разделить его, потому что в разработке форм эта форма выбора вкладок, можно сказать, слишком распространена, разделение определенно выгодно, и его функция Очень одиночный, хорошо подходит как самостоятельный компонент.
Как описать компоненты со структурами данных?
Статическая структура, наверное, понятна, так как же описать этот компонент с данными? Далее давайте рассмотрим структуру данных компонента. Прежде чем мы начнем, мы должны прояснить несколько предпосылок:
"Количество вкладок не фиксировано, вкладки связаны с содержимым дополнительных элементов, а количество дополнительных элементов не фиксировано"
Приведенное выше изображение представляет собой структуру данных, которую я придумал в первом издании, причина создания этого правила заключается в следующем:
-
Так как количество вкладок не фиксировано, удобнее всего настроить его в виде массива для рендеринга списка фронтендом (то же самое касается настройки дополнительных элементов).
-
потому чтоВкладка связана с содержимым дополнительного элемента, поэтому я напрямую встраиваю дополнительный элемент во вкладку и переключаю соответствующие дополнительные данные элемента непосредственно при переключении вкладки.
-
Поскольку есть несколько вкладок и несколько дополнительных элементов, должна быть проблема комбинированного расположения. В первой версии решения я использовал метод обработки карты, соединяя значения выбранного значения вместе, а затем получение значения конечного значения в ValueMAP. (Различные бизнес-методы, если вам не нужно иметь дело с проблемой сочетания, вы можете напрямую выводить все выбранные значения значения)
Далее логика очень гладкая: нам нужно только получить значение объединения значений, окончательно выбранное пользователем, чтобы получить целевые данные в valueMap.
Но эта схема порочна, я ее проигнорировалСложность конфигурации, чтобы логику можно было легко обрабатывать во внешнем коде. Однако это принесет бесконечные проблемы с последующей настройкой.С увеличением количества решений ситуация с комбинацией будет быстро увеличиваться. Чтобы избежать этой ямы, мне нужно немного оптимизировать valueMap.
Схема оптимизации valueMap
Как показано в коде на рисунке, исходный метод взаимно однозначного соответствия ключ-значение отменяется, и принимается режим вывода необязательного диапазона значений в соответствии с элементом вкладки.
Затем нижний индекс массива необязательных диапазонов значений получается путем обработки выбранной опции. Таким образом, конфигурация будет лучше, чем предыдущее решение, и логика фронтенда будет немного сложнее, но код фронтенда нужно написать только один раз, а конфигурацию можно будет бесчисленное количество раз.
Интерфейсная логика нового решения, наверное, такая, подождите... почему она выглядит так неуклюже? Эта логика полностью переплетена с бизнесом, не будет ли взрывом, если добавятся дополнительные элементы? Если есть комбинация между дополнительными планами, она взорвется :(
Значит ли это, что этот план более ненадежен?Можем ли мы попытаться отделить его от бизнеса?
Объединение битовых операций с компонентами формы
Введение в битовые операции JavaScript
Битовая операция предназначена для непосредственной работы с двоичными битами целых чисел в памяти Это не имеет ничего общего с тем, находится ли она в среде JavaScript, но мы можем использовать этот тип мышления битовой операции.Связанная документация по битовым операциям JavaScript, в этой статье мы в основном будем использовать для наших целей оператор побитового сдвига.
Как совместить два?
Перейдем непосредственно к коду, давайте посмотрим на картинку и поговорим--
В новой логике мы больше не видим зависимость от значения элемента аддона, а вместо этого позиционный индекс в бинарном виде. Предположим, у нас есть такой массив:
let A = [A-value-0, A-value-1, A-value-2, A-value-3]
Значения этих четырех опций соответственно -
| выбор | стоимость | индекс массива | двоичный индекс |
|---|---|---|---|
| не выбирать | A-value-0 | A[0] | 00 |
| выбрать первый | A-value-1 | A[1] | 01 |
| выбрать второй | A-value-2 | A[2] | 10 |
| выбрать все | A-value-3 | A[3] | 11 |
Это очень просто и понятно: нетрудно найти столбец бинарных индексов, где 0 означает невыбранный, 1 означает выбранный, а по позиции 1 можно узнать, какой элемент выбран или не выбран.
Давайте посмотрим на связь между нижним индексом массива и двоичным нижним индексом.После преобразования двоичного нижнего индекса в десятичный, это в точности искомый индекс массива.
Возвращаясь к коду на рисунке, вышеприведенная идея значения — это именно то, что forEach делает внутренне:
Пройдите проверенные элементы в массиве дополнений, получите двоичный индекс, принадлежащий элементу, в соответствии с его индексом, а затем выполните операцию ИЛИ для всех пройденных двоичных индексов, чтобы получить окончательный двоичный индекс, а затем преобразуйте его в реальный индекс массива для получить окончательное значение.
С помощью этой схемы мы можем получить желаемую комбинацию и получить соответствующее значение комбинации, не заботясь о количестве элементов в addonList или значении каждого элемента.Когда мы настраиваем проект, нам нужно только обратить внимание на порядок каждого значения, независимо от того, сколько элементов настроено, это не повлияет на логику внешнего интерфейса.
Также возможно изменить количество addonList в этом случае, например, их 3:
| выбор | стоимость | индекс массива | двоичный индекс |
|---|---|---|---|
| не выбирать | A-value-0 | A[0] | 000 |
| Выбери один | A-value-1 | A[1] | 001 |
| выбрать два | A-value-2 | A[2] | 010 |
| один два | A-value-3 | A[3] | 011 |
| выберите три | A-value-4 | A[4] | 100 |
| один три | A-value-5 | A[5] | 101 |
| два три | A-value-6 | A[6] | 110 |
| выбрать все | A-value-7 | A[7] | 111 |
Резюме проекта компонента
Благодаря этому дизайну компонентов формы я немного подумал о дизайне интерфейсных компонентов:
- Независимость
- Если компонент имеет одну функцию, радио должно отвечать за выбор радио без добавления какой-либо бизнес-логики или копирайтинга.
- Компоненты не должны быть слишком сложными.Поскольку компоненты разделены, не думайте, что один компонент может делать все.
- многоразовый
- Помимо удовлетворения текущих потребностей при проектировании компонентов лучше всего учитывать их универсальность. Если вы обнаружите, что она не универсальна, лучше пропишите ее в деле, и не нужно ее выделять.
- Конечно, при проектировании компонентов невозможно требовать 100% согласованных сценариев использования компонентов, чтобы возможности адаптации и расширения компонентов становились сильнее, что способствует надежности компонентов.
- нейтральный
- Максимально сведите к минимуму бизнес-связь — обеспечивайте нейтральность компонентов.
- Вы только посмотрите на это, это вообще тощая реальность :)
- легко использовать
- Насколько это возможно, пользователям нужно учитывать только ввод и вывод.
Что касается кода дела, я не уверен, что он вам нужен. При необходимости полная версия кода компонента будет добавлена позже.