React Component

데이터

프론트엔드 개발자는 사용자 인터페이스(UI)를 개발하여 사용자에게 데이터를 보여주는 역할을 담당한다.

React는 데이터를 UI로 표현하기 위해 선언적인 방식(HTML과 유사한 모양의 DSL을 사용)으로 개발한다.

백엔드는 데이터를 JSON 형태로 돌려주는 API를 제공한다. (REST API, GraphQL)

REST API

HTTP를 사용해서 서로 정해둔 스펙(end point, HTTP Method)을 활용하여 데이터를 주고받으며 통신하는 것

• GET, POST, PUT/PATCH, DELETE -> CRUD

• Resource 중심

REST API의 제약조건 REST API는 4가지 제약조건으로 자원의 식별, 메세지를 통한 리소스 조작, 자기서술적 메시지, 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어를 만족해야 하는데 이미 많은 사람들이 이 제약조건을 지키지 않아도 REST API라고 부르기 떄문에 HTTP API와 같은 의미로 사용됨

GraphQL

Facebook에서 개발한 Graph 자료구조의 Query 언어 쿼리(Query)를 통해 얻고자 하는 것을 선언하여 데이터를 얻는다.

• 쿼리를 기반으로하여 SQL과 비슷하다.

• Query(Read), Mutation(Commend: Create, Update, Delete), Subscription(Event)

REST API의 대안으로 나오게된 등장 배경

REST API를 사용할 때, 클라이언트는 필요한 데이터를 가져오기 위해 여러 개의 API 엔드포인트를 호출한다. 이때, 불필요한 데이터도 함께 전송되기 때문에 대역폭 낭비와 서버 부하 증가의 문제가 발생할 수 있다.

GraphQL은 이러한 문제점을 해결하기 위해, 클라이언트가 필요로 하는 데이터만을 선택적으로 요청하고 응답으로 받아올 수 있도록 지원한다.

JSON(Javascript Object Notation)

클라이언트와 서버간 데이터를 교환하기 위해 만들어진 포맷 By Douglas Crockford

클라이언트와 서버간의 데이터를 (HTTP)교환할 때 포맷은 JSON 형식이지만 문자열로 변환되어 주고 받는다.

이런 JSON 형식의 문자열을 사용하기 위해 JSON 내장 객체의 메서드가 제공된다.

• JSON.stringify() → JSON 객체를 문자열로 변환하는 함수

• JSON.parse() → JSON 형식의 문자열을 자바스크립트 객체로 변환해주는 함수

DSL(Domain-Specific Language)

특정한 도메인에 맞게 설계된 언어

특정 분야(도메인)에서 자주 사용되는 용어와 규칙을 갖는 언어

해당 분야에서 개발자들이 더욱 쉽게 문제를 해결할 수 있도록 도와준다.

• SQL → 데이터베이스에 관련된 문제를 해결하는 DSL 언어 (데이터베이스)

• HTML → 웹 페이지를 구성하기 위해 사용되는 DSL 언어 (웹 페이지)

• JSX → UI를 개발하기 위해 Javascript + XML 문법을 결합한 DSL 언어 (UI)

선언형 프로그래밍 vs 명령형 프로그래밍

선언형 프로그래밍

선언형 프로그래밍은 '무엇을' 해야 하는지에 초점이 맞춰짐 개발자는 원하는 결과를 선언하고 컴퓨터가 그 원하는 작업을 달성하기 위해 스스로 처리하도록 한다.

명령형 프로그래밍

명령형 프로그래밍은 '어떻게' 해야 하는지에 초점이 맞춰짐 개발자는 컴퓨터가 수행해야 할 명령문을 순차적으로 작성하고 이를 실행하여 원하는 결과를 얻는다.

함수형 프로그래밍

함수형 프로그래밍에서는 명령적으로 반복되는 작업을 추상화함으로써 동일한 작업을 선언적으로 작성할 수 있게 해준다.

컴포넌트 계층 구조

단순한 컴포넌트를 조합하여 복잡한 UI를 구현한다. → React 강력한 특징✨ 조합은 가지수를 폭발적으로 늘릴 수 있는 가장 전형적인 방법

컴포넌트를 단순하게 구현하기 위한 몇가지 기준

1. SRP(Single Responsibility Principle)

단일 책임 원칙 → 하나의 기능은 오직 하나의 책임만 가져야 한다.

모듈, class, 함수 와 같은 소프트웨어의 구성요소는 하나의 책임만을 가져야 하며, 변경이 발생할 때는 그 이유가 단 하나여야 한다는 것을 의미한다.

이 원칙을 준수하면 코드의 응집도가 높아져 코드의 확장성과 유지보수성이 높아진다.

컴포넌트가 커지고 있다면 SRP를 준수하고 있는지 점검해보자~

SOLID 원칙

Single Responsibility(단일 책임)

Open/Close(개방-폐쇄)

Liskov’s Substitution(리스코프 치환)

Interface Segregation(인터페이스 분리)

Dependency Inversion(의존 관계 역전)

2. CSS

기능별로 구분하여 작성하는 CSS 클래스 명이나 Styled Component 네이밍은 컴포넌트를 계층적으로 나누는 규칙으로 활용될 수 있다.

이러한 기준들을 적극적으로 활용하여 컴포넌트를 세부적으로 나누고, 각 컴포넌트가 명확하게 역할과 책임을 가지도록 구성할 수 있다.

3. Design Layer

구조적으로 잘 짜여진 디자인은 트리 형태인 레이어 구조로 짜여져 있다.

디자인 구조를 활용하여 컴포넌트를 세부적으로 나눌 수 있다.

4. Information Arhitecture

JSON Schema의 영향

서버에서 주는 데이터 구조를 기준으로 컴포넌트를 설계하기도 한다.

보통은 UI 작업이 먼저 진행하고 서버 API가 후에 나오기 때문에 UI 디자인에 더 적합한 형태로 서버 측 데이터를 재가공하거나, 데이터 구조를 변경해달라는 요청을 서버 개발자에게 할 때도 있다.

자연스러운 SRP를 위해서 사실상 강제되는 부분이기도 하다.

Atomic Design

우리가 잘 알고 있는 계층적 구조를 몇가지 카테고리로 묶은 방법 [자세히보기]

컴포넌트가 많아졌을때 계층 구조를 적절하게 만들 수 있는 아키텍처를 제공

아토믹 디자인에서 제시하는 가이드라인에 딱 맞춰 디자인을 하라는 것이 아니라, 아토믹 디자인의 개념을 이해하고 그에 기반하여 자신의 작업에 적용하라는 의미이다.

atoms, molecules, organisms, templates, pages 등 모든 레이어를 사용하지 않아도 됨

atoms, molecules만 사용하는곳도 많음, 그러니 프로젝트에 맞춰 커스텀

• pages에 가까워질수록 비즈니스 로직을 다수 첨가하게 되는 구조

• atoms는 순수한 레이아웃 구조만 가지고 있다고 생각하면 됨

• 커다란 규모의 프로젝트는 디자인 시스템이 별도로 있고, 디자인 시스템을 사용한 비즈니스 레이아웃의 응집으로 atoms를 사용하기도 한다. molecules는 topbar와 같은 비즈니스의 최종 결정체가 되기도함

고민하면 좋은 것들

• 해당 컴포넌트는 비즈니스에 가까운지, 공통 컴포넌트에 가까운지

  • 공통 코드에 가깝다면 공통 레이아웃을 정의하고, 해당 컴포넌트에는 마크업 로직만을 갖게하자.

• 비즈니스를 제공한다면 로직은 커스텀 훅으로 분리

  • 단순한 useState라도 커스텀 훅으로 별도로 관리하는게 좋다.

  • 비즈니스 레이아웃은 언제든지 변경될 수 있으므로 상태, 로직은 훅으로 분리

• 컴포넌트의 계층을 만들자.

  • 공통/비즈니스 등의 사용되는 관점의 계층, 코드 레벨에서 분리하기 위한 계층의 필요

Compound Pattern

• 아토믹한 상태, 레이아웃을 상호 참조하는 atomic한 프론트 환경에서 자주 사용되는 패턴

• 여러 컴포넌트들을 모아 하나의 동작으로 사용하기 위함

• 동작 구현에 필요한 상태등을 내부 context 등으로 가지고 있기에 내부 동작이 들어나지 않음

• 내부 동작이 들어나지 않기에 주석 등에 의존하여, 사용 형태가 하나로 고정되는 단점 존재

• 디자인 시스템, 혹은 여러 참조하는 레이아웃 사례에 적합함

  • ex: 버튼에 left, right에 추가적으로 들어갈 수 있는 레이아웃이 들어가는 패턴이 있다면 leftSide, rightSIde를 컴포넌트화 하여 연결하여 사용하는 등 중복 로직에 대해 케어할 수 있따.ㄴ