Блог Eleven Labs — Создание надежной системы проектирования с помощью React: основные основы

При проектировании интерфейсов вы, вероятно, уже использовали библиотеки компонентов. Однако может случиться так, что они не будут оптимально отвечать конкретным случаям или конкретным требованиям вашего приложения, особенно в конкретных бизнес-контекстах. Затем вы решаете создать экосистему, которая объединит ваши собственные компоненты, типографику, цвета, документацию и рекомендации по использованию: систему дизайна. В этой статье мы объясним, как создать надежную систему проектирования с помощью React.

Контекст

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

Система проектирования

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

Атомный дизайн

Л’Атомный дизайн — это подход к проектированию систем пользовательского интерфейса и проектированию взаимодействия. Этот подход заключается в разделении компонентов на модульные элементы: атом, молекула, организм, шаблоны и страницы.

Дизайн-токен

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

ХОРОШИЙ

Методология ХОРОШИЙ дает CSS соглашение о структурировании, именовании и организации ваших компонентов. БЭМ рассматривает композицию веб-страницы в нескольких аспектах. Бзамки, содержащие Ээлементы, и они могут различаться в зависимости от Модификаторы.

Системный реквизит

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

Выполнение

Следуя только что упомянутым основам, мы создадим систему проектирования в React с SCSS, которая позволит нам правильно использовать методологию БЭМ.

Начнем с объявления наших токенов дизайна:

// Design token - spacing.tokens.json
{
  "spacing": {
    "0": {
      "value": "0"
    },
    "xxs": {
      "value": "8px"
    },
    "xs": {
      "value": "12px"
    },
    "s": {
      "value": "16px"
    },
    "m": {
      "value": "24px"
    },
    "l": {
      "value": "32px"
    },
    "xl": {
      "value": "42px"
    }
  }
}

// Design token - color.tokens.json
{
  "color": {
    "primary": {
      "azure": {
        "value": "#3767B6"
      }
    },
    "secondary": {
      "navy": {
        "value": "#102F7D"
      },
      "cerulean": {
        "value": "#59B9F5"
      },
      "emerald": {
        "value": "#69CC97"
      },
      "purple": {
        "value": "#AB83B9"
      }
    },
    "greyscale": {
      "light-grey": {
        "value": "#C4C4C4"
      },
      "grey": {
        "value": "#9B9B9B"
      },
      "dark-grey": {
        "value": "#757575"
      }
    }
  }
}

В сотрудничестве с дизайнерами мы определили интервалы и повторяющиеся цвета в предоставленных макетах.

Давайте затем определим типы, которые могут использовать эти токены проектирования:

// tokenTypes.ts
import type { tokenVariables } from '@/constants';

export type ColorType =
  | keyof (typeof tokenVariables)['color']['primary']
  | keyof (typeof tokenVariables)['color']['secondary']
  | keyof (typeof tokenVariables)['color']['greyscale'];

export type SpacingType = keyof (typeof tokenVariables)['spacing'];

Эти типы затем можно использовать для определения:

// System Props - ColorSystemProps.ts
import type { ColorType } from '@/types';

export interface ColorSystemProps {
  /** background-color */
  bg?: ColorType;
  /** color */
  color?: ColorType;
}

// System Props - SpacingSystemProps.ts
import type { SpacingType } from '@/types';

export interface MarginSystemProps {
    /** margin */
    m?: SpacingType;
    /** margin-top */
    mt?: SpacingType;
    /** margin-right */
    mr?: SpacingType;
    /** margin-bottom */
    mb?: SpacingType;
    /** margin-left */
    ml?: SpacingType;
}

export interface PaddingSystemProps {
    p?: SpacingType;
    ...
}

export interface SpacingSystemProps extends MarginSystemProps, PaddingSystemProps {}

• тип свойства компонента

// Atomic Design - Atom/Button.tsx
import type { ColorType } from '@/types';

interface ButtonProps {
    color: ColorType;
    label: string;
    handleClick: MouseEventHandler;
}

const Button: React.FC = ({ label, color, handleClick }) => (
    <button style={{ backgroundColor: color }} onClick={handleClick}>{label}button>
);

export default Button;

Теперь перейдем к созданию наших модульных элементов. В приведенном выше примере мы создали атомарный компонент, стиль которого определяется атрибутом style. Давайте возьмем этот компонент и создадим с его помощью CSS-класс:

// Button.scss
.button {
  color: white;
  background-color: red;
  padding: var(--spacing-xs);

  &--bg-primary {
    background-color: var(--color-primary);
  }
}

// Atomic Design - Atom/Button.tsx
...
import classNames from 'classnames';
import type { ColorType } from '@/types';

import './Button.scss';

interface ButtonProps extends SpacingSystemProps {
    color: ColorType;
    label: string;
    handleClick: MouseEventHandler;
}

const Button: React.FC = ({ label, color, handleClick, p }) => (
    <button className={classNames('button', {
        [`button--${color}`]: color,
        [`p-${p}`]: p,
    })} onClick={handleClick}>{label}button>
);

export default Button;

Система проектирования требует тесного сотрудничества между представителями различных профессий (дизайнеры, разработчики, PO/PM). Чтобы это сотрудничество было эффективным, важную роль играет документация.

Документатор комментариев к системе дизайна?

В мире интерфейсной разработки документация компонентов имеет решающее значение для обеспечения визуальной и функциональной согласованности приложения, а также служит отправной точкой между дизайнерами и разработчиками. Хорошая документация позволяет перечислить доступные компоненты, варианты каждого элемента и поддерживать четкую структуру передовых практик при создании компонентов, которые будут использоваться в системе проектирования. Здесь в игру вступают различные инструменты документирования. Storybook, мощный инструмент, предлагает инновационное решение этой задачи, и именно это решение мы выбрали для наших систем проектирования в Studio Eleven Labs.

Что такое сборник рассказов?

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

Истории позволяют добавлять аннотации, подробные описания и интерактивные примеры, делая документацию более насыщенной и доступной.

• Простая интеграция и поддержка нескольких платформ.

Storybook можно очень легко интегрировать в существующий проект и адаптировать к различным техническим стекам. Независимо от того, используете ли вы React, Angular, Vue или любую другую среду или библиотеку, Storybook предлагает поддержку нескольких платформ, что придает ей некоторую гибкость.

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

• Мгновенная интерактивность

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

• Возможность повторного использования историй

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

Написание историй

А История — это визуальное представление данного компонента в его разных состояниях и разных вариантах. Каждый История позволяет манипулировать свойствами компонента для визуализации и тестирования всех его аспектов. Мы возьмем пример Organism для которого мы собираемся создать История.

// Organism - PostPreviewList.tsx
export interface PostPreviewListProps {
  posts: Partial[];
  pagination?: PaginationProps;
  isLoading?: boolean;
}

export const PostPreviewList: React.FC = ({ posts, pagination, isLoading = false }) => (
  <>
    {posts.map((post, index) => (
      <React.Fragment key={post?.slug ?? index}>
        <PostPreview
          hasMask={Boolean(pagination && index === posts.length - 1)}
          {...(post || {})}
          isLoading={isLoading}
        />
        {posts.length - 1 !== index && <Divider my="m" bg="light-grey" />}
        {posts.length - 1 === index && pagination && <Divider size="m" my="m" mx={{ md: 'xl' }} bg="azure" />}
      React.Fragment>
    ))}
    {pagination && <Pagination {...pagination} />}
  
);

Итак, у нас есть этот компонент PostPreviewList для чего мы опишем История соответствующее, в файле PostPreviewList.stories.tsx. Этот История сначала опишет исходное состояние компонента. Мы предоставим в качестве входных фиктивные данные, позволяющие отображать компонент в соответствии с контрактом интерфейса, предварительно назвав наш Историякоторый будет помещен в файл Organism.

// Organism - PostPreviewList.stories.tsx
import { Meta, StoryFn } from '@storybook/react';
import React from 'react';

import { PostPreviewList } from './PostPreviewList';

export default {
  title: 'Organism/PostPreviewList',
  component: PostPreviewList,
  args: {
    posts: Array.from({ length: 7 }).map((_, index) => ({
      contentType: 'article',
      slug: `slug-${index}`,
      title: `Titre de l'article ${index}`,
      date: '09 fév. 2021',
      readingTime: 24,
      authors: [{ username: 'jdoe', name: 'J. Doe' }],
      excerpt:
        'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed hendrerit vel tellus in molestie. Curabitur malesuada sodales consectetur. Aliquam convallis nec lacus in euismod. Vestibulum id eros vitae tellus sodales ultricies eget eu ipsum.',
    })),
  },
} as Meta<typeof PostPreviewList>;

const Template: StoryFn<typeof PostPreviewList> = (args) => <PostPreviewList {...args} />;

export const PostPreviewListWithData = Template.bind({});

Вот результат.

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

Варианты использования документа

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

export const PostPreviewListIsLoading = Template.bind({});
PostPreviewListIsLoading.args = {
  isLoading: true,
};

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

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

export const PostPreviewListWithPagination = Template.bind({});
PostPreviewListWithPagination.args = {
    pagination: {
        textNumberOfPosts: '6/156 affichés',
        numberOfPosts: 6,
        maxNumberOfPosts: 156,
        loadMoreButtonLabel: 'Afficher plus',
        onLoadMore: action('onLoadMore'),
    },
};

Статическая документация

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

Storybook предлагает нам возможность записи файлов MDXкоторые смешивают Markdown с Javascript/JSX и позволяют создавать как статическую, так и визуальную документацию.

Попробуем собрать пример в файл Colors.stories.mdx который будет документировать токены дизайна, касающиеся цветов, доступных в нашем приложении, тех, которые мы имели возможность увидеть выше.

// Documentations - Colors.stories.mdx
import { Meta } from '@storybook/addon-docs'
import { tokenVariables } from '../constants'

"Documentations/Design Tokens/Colors" />

# Colors

> Present color palette used by both design and engineering.

{Object.entries(tokenVariables.color).map(([categoryKey, tokenColorsByCategory]) => (
  <div key={categoryKey}>
    {categoryKey}
    <table style={{ width: '100%' }}>
      <thead>
        <tr>
          <th>Nameth>
          <th>Valueth>
          <th>Previewth>
        tr>
      thead>
      <tbody>
        {Object.entries(tokenColorsByCategory).map(([tokenName, token]) => (
          <tr key={tokenName}>
            <td>{tokenName}td>
            <td>{token.value}td>
            <td>
              <div
                style={{
                  boxSizing: 'border-box',
                  width: '200px',
                  height: '50px',
                  backgroundColor: token.value,
                }}
              />
            td>
          tr>
        ))}
      tbody>
    table>
  div>
))}

Что дает нам это в результате.

Чтобы получить конкретное и подробное представление расширенной документации, мы направляем вас на Сборник рассказов о Design System d’Eleven Labs.

Заключение

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

Инструменты и концепции, представленные в этой статье, являются результатом нашего опыта работы с системами проектирования в рамках Студия Одиннадцать Лабораторий. Это позволило нам внедрить комплексные и надежные системы проектирования для наших клиентов, а также для наших внутренних проектов.