Представляем одноэлементный шаблон

1656593061 predstavlyaem odnoelementnyj shablon

автор Диего Хаз

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

1*safLOvm16NWX1Z4mPBHNCQ

Еще в 2002 году – когда я начал создавать материалы для Интернета – большинство разработчиков, включая меня, структурировали свои макеты с помощью <table> теги.

Только в 2005 году я начал придерживаться веб-стандартов.

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

Я узнал семантику и доступность, а затем начал использовать правильные теги HTML и внешние CSS. Я гордо добавлял эти значки W3C на каждый веб-сайт, который я создал.

1*pFL99e3lxpYN-Fp24HfdBw

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

Прошло время. Чтобы изолировать многократные части интерфейса, я использовал PHP, шаблонные системы, jQuery, Polymer, Angular и React. Этим последним, в частности, я пользуюсь последние три года.

Шло время, код, который мы написали, все больше отличался от того, который подавали пользователю. Сегодня мы транспилируем наш код многими разными способами (например, используя Babel и TypeScript). Мы пишем ES2015+ и JSX, но исходный код будет только HTML и JavaScript.

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

И у меня есть кое-что для тебя.

Одноэлементный шаблон (Singel)

Я не знаю точно, сколько компонентов я написал все еще. Но если совместить Polymer, Angular и React вместе, то могу смело сказать, что эта цифра превышает тысячу.

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

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

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

Нет ничего надежнее, чем а <div>.

Используя компонент, вы зададите себе один или несколько из этих вопросов:

  • Вопрос №1: Что делать, если мне нужно передать props вложенным элементам?
  • Вопрос №2: не повредит ли это приложение по какой-либо причине?
  • Вопрос №3: Что делать, если я хочу пройти id или другой атрибут HTML?
  • Вопрос № 4: Могу ли я стилизовать его мимоходом className или style реквизит?
  • Вопрос №5: как насчет обработчиков событий?

Надежность означает, в этом контексте не нужно открывать файл и смотреть на код, чтобы понять, как он работает. Если вы имеете дело с а <div>, например, вы сразу узнаете ответы:

Это группа правил, которую мы называем Singel.

Разработка, управляемая рефакторингом

Сделайте это, а затем сделайте это лучше.

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

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

Некоторые из них легко абстрагировать сразу: Button, Image, Input. То есть, те компоненты, которые имеют прямую связь с элементами HTML. В других случаях вы сможете идентифицировать их только тогда, когда начнете дублировать код. И это хорошо.

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

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

Положите их в отдельную папку. elements, atoms, primitives — следовательно, когда вы импортируете из него компонент, вы будете уверены в правилах, которым он придерживается.

Практический пример

В этой статье я сосредоточу внимание на React. Те же правила можно применить к любой библиотеке на основе компонентов.

При этом считайте, что у нас есть a Card компонент. Он состоит из Card.js и Card.cssгде у нас есть стили для .card, .top-bar, .avatarи других селекторов классов.

1*Sm0TM1LOvrWi0WBVjVRIsA

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

Правило №1: Отображайте только один элемент

Он состоит из Avatar.js и Avatar.cssкоторый имеет .avatar стиль, из которого мы вышли Card.css. Это дает просто <img>:

Вот как мы будем использовать его внутри Card и другие части программы:

<Avatar profile={profile} />

Правило №2: Никогда не нарушайте программу

An <img> не нарушит программу, если вы не настроите pass атрибут src, даже если он обязателен. Наш компонент, однако, будет сломать всю программу, если мы этого не сделаем pass profile.

1*aAB2QAEHkWxMBo-UFaCsUA

React 16 предлагает новый метод жизненного цикла под названием componentDidCatch, который можно использовать для изящной обработки ошибок внутри компонентов. Несмотря на то, что внедрение границ ошибок в вашей программе является хорошей практикой, это может маскировать ошибки внутри нашего отдельного элемента.

Мы должны убедиться в этом Avatar является надежным сам по себе, и предполагаем, что даже необходимые параметры могут не предоставляться родительским компонентом. В этом случае кроме проверки или profile существует к использованию, мы должны использовать Flow, TypeScriptили PropTypes предупредить об этом:

Теперь мы можем воспроизвести <Avatar /> без реквизитов и посмотрите на консоли, что он ожидает получить:

1*5Cjn18Fr2n_O1wHMGff4wQ

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

Правило №3. Отображайте все атрибуты HTML, передаваемые как props

Пока наш единственный элемент использовал специальную опору под названием profile. Следует избегать использования пользовательских реквизитов, особенно если они сопоставлены непосредственно с атрибутами HTML. Узнайте об этом ниже, в Предложении №1: избегайте добавления пользовательских реквизитов.

Мы можем легко принять все атрибуты HTML в наших отдельных элементах, просто передав все props вплоть до основного элемента. Мы можем решить проблему с пользовательскими реквизитами, ожидая соответствующих атрибутов HTML:

Теперь Avatar больше похож на элемент HTML:

<Avatar src={profile.photoUrl} alt={profile.photoAlt} />

Это правило также включает визуализацию children когда, конечно, базовый элемент HTML принимает это.

Правило №4: Всегда объединяйте стили, передаваемые как опорные

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

Внутренний стиль отдельного элемента эквивалентен стилю, который браузеры применяют к нативным элементам HTML. При этом наш Avatarпри получении a className prop, не должен заменять внутренний, а добавлять его.

Если бы мы применили внутрь style поддержка к Avatarэто можно легко решить, используя распространение объектов:

Теперь мы можем надежно применить новые стили к нашему единственному элементу:

<Avatar  className="my-avatar"  style={{ borderWidth: 1 }}/>

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

Правило №5: Добавьте все обработчики событий, передаваемые как реквизиты

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

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

Предложения

Предложение №1: избегайте добавления собственных реквизитов

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

Использование Avatar Например, по определенной эксцентричности конструктора предположим, что у вас есть некоторые места, где аватар должен быть в квадрате, а другие где он должен быть закруглен. Вы можете подумать, что было бы хорошей идеей добавить rounded поддержка к Avatar.

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

Если вы продолжаете использовать уникальные и описательные имена и создавать надежные компоненты, у вас могут быть сотни из них. Он по-прежнему будет хорошо ремонтироваться. В документации будут названия компонентов.

Предложение №2: Получите базовый элемент HTML в качестве сопротивления

Не каждый собственный реквизит есть злом. Часто вы хотите изменить базовый элемент HTML, который отображается одним элементом. И добавление специального реквизита – единственный способ добиться этого.

Распространенным примером является воспроизведение a Button как <;a>:

<Button as="a" href="  Go To Google</Button>

Или как другой компонент:

<Button as={Link} to="/posts">  Posts</Button>

Если вас интересует эта функция, я рекомендую просмотреть ReaKit, инструментарий React UI, созданный с учетом Singel.

Проверьте отдельные элементы с помощью Singel CLI

Наконец, прочитав все это, возможно, задались вопросом, существует ли инструмент для автоматической проверки ваших элементов по этому шаблону. Я разработал такой инструмент, Singel CLI.

Если вы хотите использовать его в текущем проекте, я предлагаю создать новую папку и начать размещать туда свои элементы single.

Если вы используете React, вы можете установить singel через npm и запустите это следующим образом:

$ npm install --global singel$ singel components/*.js

Выход будет подобным этому:

1*fE7wp8PS2EG7043OYcQhkg

Другой хороший способ – установить его как зависимость разработчика в вашем проекте и добавить в него сценарий package.json:

$ npm install --dev singel
{  "scripts": {    "singel": "singel components/*.js"  }}

Затем просто запустите npm сценарий:

$ npm run singel

Спасибо, что читаете это!

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

Добавить комментарий

Ваш адрес email не будет опубликован.