Потому что, в конце концов, это все равно 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 -
- Datatable.vue
- DatatableDateRangeFilter.vue
- DatatableCheckboxFilter.vue
Два компонента фильтра, DatatableDateRangeFilter.vue
и DatatableCheckboxFilter.vue
, являются дочерними компонентами, предназначенными для вложения в основной элемент Datatable.vue
через его <slot></slot>
элемент ¹.
Чем это отличается от примера ‹search-form›?
Архитектурные решения - это всегда вызов. Вы можете посмотреть на этот снимок экрана с данными и задаться вопросом, почему поле поиска не является отдельным компонентом Vue, или почему нет разбивки на страницы, или раскрывающегося списка на каждой странице и т. Д., Но обычно нет черно-белого ответа. Обычно все сводится к пониманию того, кто будет использовать ваш компонент, а также к тому, как он будет использоваться сейчас и в будущем.
Я решил не создавать их как отдельные компоненты, потому что, в моей интерпретации, на самом деле это только функции, которые либо включены, либо выключены, и поэтому были созданы для переключения с помощью атрибута в элементе <sj-datatable>
, т.е. <sj-datatable :hide-features="['search', 'pagination', 'per-page', /* etc */]">
).
Фильтры, однако, должны были быть динамическими как по количеству, так и по типам - это означало, что нам нужно было либо передать какой-то сложный объект в свойство компонента (а не переключатель включения / выключения, как указано выше), либо фильтры, разделенные по времени, разбивались на собственные компоненты.
Примечание. Если бы был только один фильтр даты или один фильтр с флажками - возможно, с некоторыми параметрами - это, вероятно, также могли быть «функциями», но мы собирались нужны от нуля до нескольких фильтров, все с разными параметрами, в зависимости от типа данных, которые мы загружали в каждую таблицу данных.
Я до сих пор не понимаю, о чем ты говоришь
Наша цель здесь -
- Помогите тому, кто не так хорошо знаком с Javascript, по-прежнему иметь возможность развертывать наши сложные компоненты без нашей помощи (дайте возможность нашим коллегам!).
- Создавайте автономные блоки 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 за то, что он был моим фотографом и редактором этой статьи 👊