인터페이스 사용자 인터페이스 구성 요소

최근 몇 년 동안 전단 개발은 내 생활의 중요한 부분이 되었다.그러나 몇 년 전에 작업을 시작했을 때 API가 무엇인지 잘 몰랐습니다.나는 그들과 함께 일하지만, 나는 그것이 도대체 무엇인지, 무엇을 건설해야 하는지도 상관하지 않는다.UI에서 인터페이스의 개념이 무엇인지 알고 있지만 API 알파벳 "I"와의 관계는 알 수 없습니다.어느 정도 협업이 더욱 중요해졌다.당신의 동료는 당신의 일을 사용하고 이해할 수 있어야 합니다.이것이 바로 제가 프런트엔드 개발에서 API와 UI 간의 관계를 보기 시작한 곳입니다.

무엇이 인터페이스입니까?

전단 엔지니어로서 시종 업무의 중용성을 고려해야 한다.다른 한편, 우리의 업무도 사용자에게 사용할 수 있고 접근할 수 있어야 한다.이 두 개념은 현대 작업 방식과 결합되어 있는데 그 중에서 디자인 시스템은 주의력의 중심이다.AsAlla Kholmatova describes in her book 설계 시스템은 재사용 가능한 모델을 포함한다.그러나 어떤 것들을 어떻게 중용할 수 있는지, 특히 내용 모델 자체가 상당히 복잡한 상황에서?
이것이 바로 인터페이스 개념이 작용하는 곳이다.ever so TrustlyWikipedia는 다음과 같은 인터페이스를 정의했다.

An interface is a shared boundary across which two or more separate components of a computer system exchange information

내 앞안경으로 이 정의를 보았을 때, 나는 단어component를 직접 보았다.우리가 대부분의 디자인 시스템을 만드는 방식은 바로 두 개 이상의 단독 UI 구성 요소가 협동하는 것이다.예를 들어, React 에서는 서브어셈블리 도구를 통해 상위 어셈블리에서 서브어셈블리에 데이터를 제공합니다.그렇다면 이것은 전단 개발에서 우리가 인터페이스를 설계하고 개발하는 곳입니까?네, 그렇습니다.
앞에서 말한 바와 같이 이것은 인터페이스가 역할을 발휘하는 유일한 곳이 아니다.사용자가 단추를 누르거나 폼을 작성하여 제출할 때, 그나 그녀는 우리의 구성 요소와 상호작용을 하고 있다.사용자와 상호 작용하는 UI는 인터페이스가 정의하는 공유 경계입니다.사용자의 상호작용은 우리의 구성 요소에 그나 그녀의 의도적인 정보를 전달하는 방식이다.

부품 해부학

따라서 구성 요소를 설계하고 개발할 때 우리는 두 가지 유형의 인터페이스를 처리해야 한다.이 구성 요소 중 여러 개를 조합하여 사용자들이 사용할 수 있는 UI를 만들어 시스템에 연결할 수 있습니다.너무 좋아요.저희 끝났나요?전혀 그렇지 않다.우리가 인터페이스의 일부 내용을 변경할 때, 그것은 같은 구성 요소의 다른 인터페이스에 영향을 줄 것이다.이 점을 더욱 잘 이해하기 위해서 우리는 반드시 부품 해부를 이해해야 한다.

보시다시피 UI 구성 요소는 상호 작용하는 몇 가지 부분으로 구성되어 있습니다.사용자가 단추를 눌러 UI와 상호작용할 때 구성 요소 내부에서 논리가 촉발됩니다.논리에 따라 구성 요소 내에서 몇 가지 상황이 발생할 수 있다.구성 요소의 내부 상태가 업데이트되어 백엔드에 요청을 보내거나 사용자에게 정보를 제공합니다.그러나 구성 요소 내부에 중요한 경로가 없습니다.API를 통해 다른 구성 요소에 정보를 제공할 수 있습니다.이것은 다른 구성 요소가 리셋 함수 (예를 들어 단추 구성 요소의 onClick 를 제공하여 구성 요소에 연결했을 때만 유효합니다.
구성 요소는 다른 구성 요소의 API를 통해 다른 구성 요소에 정보를 제공할 수 있습니다.다른 구성 요소는 API를 통해 구성 요소에 정보를 제공할 수 있습니다.이것은 다른 엔지니어들이 사용하는 인터페이스다.다른 구성 요소가 API를 통해 연결되면 우리 구성 요소는 논리를 실행합니다.논리에 따라 내부 상태를 업데이트하거나 정보를 제공하거나 정보에 따라 UI를 업데이트합니다.
마지막으로, 우리 구성 요소는 API에서 다른 구성 요소와 어떻게 연결하는지 설명합니다.그것은 어떤 종류의 정보를 수신할 수 있는지, 그리고 언제 정보를 되돌릴 수 있는지를 설명한다. (예를 들어 리셋 함수, 예를 들어 onClick.일반적으로 다른 엔지니어가 UI 구성 요소의 내부를 모른다고 가정할 수 있습니다.따라서 인터페이스는 우리가 다른 사람이 우리의 업무를 어떻게 사용하고 우리의 업무와 상호작용하기를 원하는지 묘사하는 방식이 되었다.그러나 다른 사람들이 어떻게 상호작용을 해야 하는지 알 수 있도록 우리는 어떻게 우리의 인터페이스를 묘사합니까?

The interfaces become a way to describe how we want others to use and interact with our work

설명 인터페이스

적당한 설계를 통해 당신의 사용자는 이미 이 문제를 부분적으로 해결했습니다.사용자에게 좋은 시각 대기열을 제공하여 그들이 어디에 있는지, 그리고 당신의 구성 요소와 어떻게 상호작용하는지 알게 하는 것이 좋은 첫걸음입니다.두 번째 단계는 설계를 실현하는 것이다.모든 사용자가 상상하는 것처럼 UI와 상호작용할 수 있는 것은 아니다.이것은 여러 가지 원인이 있을 수 있지만, 매우 큰 원인은 장애일 수 있다.사용자의 일부가 실명되었을 때, 그나 그녀는 화면 판독기를 사용하여 구성 요소와 상호작용을 할 수 있습니다.UI 디자인은 변경할 필요가 없지만 구현 단계에서 이러한 용례를 고려합니다.이 필드는 accessibility 또는 a11y 라고 합니다.
그러나 본고의 나머지 부분에서 나는 엔지니어의 인터페이스나 API를 토론하고 싶다.다른 엔지니어가 UI 구성 요소와 어떻게 상호작용하기를 원하는지 설명하는 것은 간단한 작업이 아닙니다.엔지니어로서, 나를 포함해서, 우리는 항상 우리의 일은 말하지 않아도 안다고 생각한다.사실은 그렇지 않다.만약 우리가 원한다면, 우리는 서로 다른 등급의 엔지니어가 우리의 일을 사용할 수 있도록 최소한 몇 가지 일을 묘사해야 한다.

UI 구성 요소에 액세스할 수 있는 API

각 API에 대해 그들이 어떻게 사용하고 그 목적이 무엇인지 (예를 들어 사용자 인터페이스 구성 요소의 스타일에 어떻게 영향을 미치는지 설명).

예제에서는 실제 결과(UI)와 API 입력의 서로 다른 조합의 영향을 보여 줍니다.

당신은 여러 가지 방식으로 상술한 목표를 실현할 수 있습니다.가격 인하(.md 파일(예: README.md에서 대량의 문서를 작성할 수 있습니다.흥미로운 선택은 문서 사이트를 만드는 것이다.구성 요소와 상호작용을 할 수 있습니다.만약 이것이 큰 투자를 필요로 한다면 Gitbook나 Storybook 같은 도구를 사용하는 것은 UI 구성 요소를 광범위하게 기록하는 좋은 기술이고 투자가 매우 낮다.

API React 가이드

지금까지, 이것은 매우 많은 텍스트, 너무 적은 예이다.따라서 React 설명 API를 사용하는 지침에 대해 살펴보겠습니다.이 예시들이 다른 프레임워크에도 적용될 수 있기를 바랍니다.React에서api는 사용자가 정의한 것입니다props.몇 가지 속성을 가진 작은 단추의 예시를 봅시다.

const Button = ({ onClick, variant, children, override, className, type }) => {
  return (
    <button
      onClick={onClick}
      type={type}
      className={`${override.defaultClassName} ${className}`}
      data-variant={variant}>
      {children}
    </button>
  );
};

Button.propTypes = {
  variant: PropTypes.oneOf(['primary', 'stroke', 'flat']).isRequired,
  onClick: PropTypes.func.isRequired,
  override: PropTypes.object
};

Button.defaultProps = {
  variant: 'primary',
  className: '',
  override: {
    defaultClassName: 'btn'
  }
};

맨 위에서 우리는 실제 구성 요소를 보았다.return 문장에서 우리는 생성되고 있는 UI를 보았지만 이 도구들을 어떻게 응용하는지 볼 수 있다.더 중요한 것은 이 예에서 Button.propTypes과Button.defaultProps이다.전자는 우리가 기대하는 모든 도구의 값의 유형과 필요한지 설명하는 반응 방식이다.variant 도구에 대해 우리는 우리가 가지고 있는 값을 제한한 것을 볼 수 있다.defaultProps를 통해 구성 요소가 사용하는 기본값을 정의했습니다.누군가가 우리의 구성 요소를 사용할 때, 기본값을 사용하는 것은 불필요한 부작용을 피하는 좋은 방법이다.정의되지 않은 경우 className 를 얻을 수 있습니다.그러나 기본값을 빈 문자열로 설정하기 때문에 이 빈 문자열은 사용되지 않습니다undefined.누군가가 undefined라는 CSS 클래스를 만들 때 잠재적인 부작용을 피할 수 있습니다.
그 중 이상하게 보이는 도구 중 하나는undefined.단추에 override 라는 기본 클래스 이름을 사용했다고 가정하십시오.이것은 합리적이고 좋은 명칭이지만 다른 프로젝트에 종사하는 개발자들은 서로 다른 기본 클래스를 사용할 수 있다..btn 아이템에서 일반적으로 사용하는 기본 내부 변수를 덮어쓸 수 있습니다.이상적인 경우, 그것은 거의 사용되지 않지만, 이것은 다른 사람이 사용할 수 있도록 구성 요소를 더욱 강하게 하는 간단한 방법이다.단, 개발자로서 매번 설정하기를 원하지 않습니다override.이 경우 override.defaultClassName 구성 요소를 포장할 새 구성 요소를 만들 수 있습니다.이것은 다른 개발자들이 우리 구성 요소의 내부 논리를 이해해야 하는 것을 피했다.

const PrimaryButton = (props) => (<Button
 variant="primary"
 override={{ defaultClassName='company-btn' }}
 {...props}
/>);

이제 어떡하지?

구성 요소를 연결하는 것은 매우 어렵다.UI 구성 요소를 사용하는 다른 개발자는 내부에 관심이 없을 수 있습니다.그러나 그들이 어떻게 사용하고 상호작용하는지 깨닫도록 해야 한다.마지막으로, 그것들은 사용자 인터페이스에 영향을 줄 것이다.사용자는 우리의 구성 요소와 어떻게 상호작용하는지 알아야 한다.이를 실현하려고 할 때 사소한 것부터 시작합니다(예를 들어 API의 명칭 약정).그곳에서, 너는 본고에서 기술한 것보다 더 좋은 인터페이스 방식을 확장하고 찾을 수 있다.
본문은 kevtiq.co에 최초로 발표되었다