Потому что, в конце концов, это все равно HTML, CSS и Javascript.

Автор Ян Джонсон, старший инженер по передней части в Skilljar

Шучу, они не ненавидят меня, они ненавидят Javascript - но кто бы не стал, когда мы продолжаем перестраивать наши инструменты каждые несколько лет 🙄

В мои времена…

По большому счету, реактивные фреймворки (и под этим я подразумеваю декларативные, а не императивные, ala Vue, React, Angular и т. Д. ) молоды - jQuery существует с 2006 года и является первым из Реактивные фреймворки набирают обороты в 2012 году.

У нас было немного больше времени с этими новыми фреймворками, чем было без (да, я знаю, что Интернет существовал до jQuery, но это был темное время; вы должны увидеть мой первый сайт Geocities).

Затем, в масштабе самих реактивных фреймворков, Vue молод - AngularJS появился в 2012 году, React в 2014 году (снова Angular в 2015 году, на этот раз без «JS» в его названии 👍) и Vue в 2015 году.

Шесть лет и четыре фреймворка? Понятно, что не каждый разработчик хочет (или у него есть время) вскакивать на каждую новую структуру Javascript, которая захватывает мир штурмом. Все, что мы, как фронтенд-разработчики, можем сделать, чтобы завершить часть этой магии, может немного облегчить жизнь нашей серверной части, специалистам по обеспечению качества, инженерам службы поддержки и т. Д.

Для чего нужен этот урок истории?

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

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

Итак, «мой» код? Это тоже их кодекс.

Так же, как в основных языках (Node с NPM, Ruby с Gems, PHP с Composer, Python с PIP и т. Д.) У всех есть пакеты - реактивные фреймворки позволяют нам объединить сложный HTML, CSS и Javascript в «компоненты», которые все разработчики (назад -end, другой интерфейс, младший) можно реализовать без необходимости разбираться во внутреннем устройстве.

Так как же мне тогда сделать мир лучше?

В конце концов, сервер все равно выплевывает HTML, CSS и Javascript, так что давайте не будем чрезмерно усложнять эту компонентную архитектуру, изобретая колесо.

Или не это - назовем это <search-form> примером

Нет причин заново изобретать совершенно новую, настраиваемую спецификацию HTML для вашего сайта; это только лишает других возможности осмыслить весь ваш интерфейсный код - и помните, что он по-прежнему выводится как HTML, CSS и Javascript.

Хорошо ... тогда что мне СЛЕДУЕТ делать?

Что, если бы я сказал вам, что ваши компоненты не должны быть чрезмерно сложными - что вы можете писать впечатляющие современные компоненты, которые все равно будут легко понятны всем?

Например, в Skilljar мы недавно запустили новый компонент Vue Datatable, который выглядит примерно так:

Реализовано с этим -

Мы объединили всю сложную функциональность таблицы данных в то, что представляет собой не более чем обычный HTML-элемент с двумя маленькими дочерними фильтрами 🤯 (это смайлик с взрывом головы, если вы его не видите).

И по-прежнему используя только три однофайловых компонента Vue -

  1. Datatable.vue
  2. DatatableDateRangeFilter.vue
  3. DatatableCheckboxFilter.vue

Два компонента фильтра, DatatableDateRangeFilter.vue и DatatableCheckboxFilter.vue, являются дочерними компонентами, предназначенными для вложения в основной элемент Datatable.vue через его <slot></slot> элемент ¹.

Чем это отличается от примера ‹search-form›?

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

Я решил не создавать их как отдельные компоненты, потому что, в моей интерпретации, на самом деле это только функции, которые либо включены, либо выключены, и поэтому были созданы для переключения с помощью атрибута в элементе <sj-datatable> , т.е. <sj-datatable :hide-features="['search', 'pagination', 'per-page', /* etc */]">).

Фильтры, однако, должны были быть динамическими как по количеству, так и по типам - это означало, что нам нужно было либо передать какой-то сложный объект в свойство компонента (а не переключатель включения / выключения, как указано выше), либо фильтры, разделенные по времени, разбивались на собственные компоненты.

Примечание. Если бы был только один фильтр даты или один фильтр с флажками - возможно, с некоторыми параметрами - это, вероятно, также могли быть «функциями», но мы собирались нужны от нуля до нескольких фильтров, все с разными параметрами, в зависимости от типа данных, которые мы загружали в каждую таблицу данных.

Я до сих пор не понимаю, о чем ты говоришь

Наша цель здесь -

  1. Помогите тому, кто не так хорошо знаком с Javascript, по-прежнему иметь возможность развертывать наши сложные компоненты без нашей помощи (дайте возможность нашим коллегам!).
  2. Создавайте автономные блоки HTML, CSS и Javascript, которые можно копировать / вставлять с очевидными и не требующими пояснений свойствами.

Мы хотим, чтобы добавление новой таблицы данных было таким же простым, как если бы серверный разработчик создавал свою собственную конечную точку API и копировал / вставлял некоторые предыдущие <sj-datatable> реализации и размышлял:

«Эй, если я просто обновлю свойства api-endpoint и csv-endpoint и… нам не нужны фильтры прямо сейчас, поэтому я удалю их - и… готово? Черт возьми.

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

Хорошо, дайте мне несколько советов, или я просто украду вашу таблицу данных ...

Нет! Я верю в тебя!

Во-первых, завершите достаточно сложную, многоразовую функциональность, чтобы сэкономить время и здравомыслие, то есть не переписывайте спецификацию HTML своими собственными <customButton> и <customInput> компонентами.

Вместо этого, который (вероятно) чрезмерно абстрагирован и (опять же, вероятно) раскрывает внутренние компоненты, которые на самом деле не предназначены для доступа другим разработчикам -

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

Во-вторых, ограничьте область видимости стилей вашего компонента только самим собой, в компоненте Vue из одного файла это выглядит так:

И наконец - документ, документ, документ.

Плохая документация - это проклятие всего нашего коллективного существования, поэтому, если вы собираетесь взяться за создание этих прекрасно повторно используемых пользовательских компонентов для своей организации - задокументируйте их!

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

Вот как выглядит (минимальная) спецификация для нашего Vue Datatable -

Так что.

Я имею в виду, эээ ... вот оно что!

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

¹ Хромая сноска

К сожалению, компоненты не могут прослушивать события, генерируемые чем-либо в их тегах <slot>, поэтому внутри этих <sj-datepicker> мы не можем генерировать событие on-date-selected и прослушивать его в компоненте <sj-datatable> для динамического обновления наших данных.

Я пробовал получить разъяснения, но без особого успеха - https://github.com/vuejs/vue/issues/8656, так что посмотрим, куда это пойдет, поскольку два ранее уже был закрыт без лишнего.

Хотите узнать больше о Skilljar? Посетите нас на https://www.skilljar.com/. Мы будем рады поговорить с вами, если вы хотите присоединиться к нашей команде. Вы можете узнать больше об открытых вакансиях на странице https://www.skilljar.com/about/careers/.

Благодарю моего коллегу Huy Ngo за то, что он был моим фотографом и редактором этой статьи 👊