Создание компонентов Adminlte vue. Часть 1. Проектирование компонента API.

Прочтите перед Создание компонентов Adminlte vue, часть 0. Введение.

Позвольте мне показать вам рабочий процесс, который я использую каждый раз, когда конвертирую простой HTML-компонент AdminLTE (например, окна, предупреждения, диалоговые окна и т. Д.) В однофайловый компонент Vue.

Я начну с одного из наиболее часто используемых компонентов AdminLTE: виджетов (иначе говоря, ящиков) вроде:

Откройте исходный HTML-код:

Https://adminlte.io/themes/AdminLTE/pages/widgets.html

Код HTML:

Пришло время определить различные виды виджетов / блоков и поведения, связанные с компонентом, чтобы мы могли создать полезный и простой в использовании компонент Vue Интерфейс прикладного программирования.

Официальная документация Vue.js в разделе Создание многоразовых компонентов делит компоненты Vue.js на три части:

• Свойства, используемые для передачи данных в компонент. Вы можете видеть реквизит как «параметры функции / метода».
• Слоты позволяют внешней среде составлять компонент с дополнительным содержанием.
• События позволяют компоненту вызывать побочные эффекты во внешней среде.

Я также рекомендую прочитать Руководство по стилю компонентов Vue.js Пабло Энрике с множеством полезных советов по созданию компонентов Vue.js.

Сначала мы сосредоточимся на свойствах и изменениях в поведении компонентов, связанных с его стилем (CSS). Каждый компонент может изменить свой пользовательский интерфейс / внешний вид:

• Изменение цвета: adminlte предопределяет некоторые цвета так же, как и многие CSS-фреймворки, такие как Boostrap. AdminLTE использует Меньше, и вы можете увидеть, как предопределенные цвета определены в файле box.less:

Итак, у нас есть 6 типов / поведения ящиков в зависимости от его цвета. Поэтому кажется разумным использовать свойство цвета, позволяющее пользователям указывать, какой цвет они хотят использовать при рендеринге виджета окна AdminLTE. Итак, возможный API может быть:

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

• Сплошной заголовок: как вы видите на скриншоте выше, заголовок поля может иметь или не иметь фон. Поэтому кажется разумным создать твердую опору, которая работает как переключатель / логическое значение, активируя твердый заголовок или нет.
• Сворачиваемое и съемное поведение: поскольку пользователи, использующие компонент, иногда могут захотеть создать простые блоки без дополнительных функций или блоки, которые можно удалить или свернуть. Так возникают две дополнительные опоры, складывающиеся и съемные. Обратите внимание, что расширяемое поведение противоположно складному (здесь вы можете выбрать, хотите ли вы или нет добавлять дополнительную расширяемую опору, но я думаю, что здесь нет необходимости, это только дополнительная, которая добавляет сложность и поднимает новые проблемы, такие как проверка логического состояния, например, предотвращение несогласованности сворачиваемые / расширяемые значения).
• Исходное свернутое / развернутое состояние: много раз мы будем использовать реквизиты, отвечающие за установку компонента начального состояния. Обычно этот реквизит сопоставляется с переменными данных. Помните, что Vue 2 использует односторонний поток данных, поэтому свойства нельзя изменить внутри компонентов, поэтому мы используем следующий шаблон:

Умммм, а здесь много подобных переменных нет? Как запомнить, какую переменную мы должны изменить, когда мы хотим изменить состояние компонента? Например, если я хочу свернуть окно, которое я изменяю: isCollapsed или свернутый? Хороший вопрос, позвольте мне объяснить вам некоторую полезную информацию:

• Если вы попытаетесь изменить компонент prop изнутри компонента, vue.js покажет нам ошибку, поэтому всегда меняйте переменные реактивных данных внутри компонентов
• Свойства компонентов могут быть изменены только родительскими компонентами, связывающими через v-bind переменную реактивных данных, поэтому свойства являются единственным возможным интерфейсом, вызывающим изменения внутри компонентов извне.

Позвольте мне использовать свернутый в качестве примера. Если вам никогда не придется изменять свернутую опору изнутри компонента, вы можете избежать использования isCollapsed и использовать свернутую опору как переменную только для чтения, которая может быть изменена только вне компонента. . Но как в нашем случае свернуть окно при щелчке по виджету сворачивания (значок с минусом)? Этот виджет является частью шаблона компонента, поэтому мы захотим изменить свойство свернутого, но оно доступно только для чтения! Вот почему две одинаковые (но разные) переменные, одна представляет компонент текущего состояния (данные), а другое начальное значение (свойство).

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

и вуаля! компонент снова реагирует на изменения в props!

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

Хорошо, пора поговорить о том, как мы будем использовать слоты в наших компонентах. Как говорится в документации Vue.js:

Слоты позволяют внешней среде составлять компонент с дополнительным содержимым.

Иногда у нас возникает соблазн использовать реквизит, когда слоты - лучший вариант. Например, как я могу определить заголовок окна? конечно, мы можем использовать свойство строки заголовка для установки заголовка окна:

Но учтите следующие минусы:

• Длина заголовка: это всего лишь эстетика, но я не сторонник больших значений реквизита.
• Сложные заголовки: не всегда заголовки могут быть простыми, поскольку мы можем использовать HTML для изменения внешнего вида заголовков, например, используя интервалы или значения заголовков (h1, h2 и т. д.) со стилями css или без них.

Лучшим вариантом здесь является использование слотов. Но будьте осторожны, мы можем использовать только слот в качестве основного слота / слота по умолчанию, и мы должны установить не только заголовок, но и тело поля! В этих случаях мы будем использовать Именованные слоты. Для тела мы будем использовать слот по умолчанию / основной:

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

Последними, но не менее важными являются события, с событиями, которые вы решаете, как ваш компонент «будет» взаимодействовать с внешним кодом. Например, мы должны решить, хотим ли мы, чтобы другой код уведомлялся об изменениях состояния в нашем компоненте. Ящики могут изменять состояние по-разному (свернутые в развернутые, существующие в удаленные, из нормального состояния в состояние загрузки и т. Д.). Так, например, мы решим инициировать следующие события:

• свернутый: срабатывает, когда форма изменения состояния компонента развернута до свернутой.
• расширено: срабатывает, когда форма изменения состояния компонента свернута в развернутую.
• удалено: поле удалено
• Другое…

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

Часто при использовании компонентов из других developents я пропускаю больше событий, которые позволяют мне «зацепить» их код, не касаясь ни одной строчки их кода, поэтому я предпочитаю «злоупотреблять» определением событий, потому что пользователи моих API всегда могут игнорировать события.

После того, как было решено, какие события запускать, еще один хороший вопрос: где мне запускать события? Позвольте мне прокомментировать вам два варианта, какой из них я использую:

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

• Наблюдатели: или мы можем использовать наблюдателей:

Я предпочитаю второй вариант, потому что с первой версией мы всегда должны помнить о пользовательском методе remove () вместо изменения непосредственно удаляемой переменной.

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

Если вам не терпится увидеть окончательный код по адресу:

Нажмите ❤️, если вам понравилось это читать, и поделитесь ею!

До свидания!