Headless한 데이터 테이블 컴포넌트 개발기

목차

Intro

Why Headless

Headless Component란

A component that doesn’t have a UI, but has the functionality.

Headless로 얻을 수 있는 장점

useDataTable Hooks 개발/고민과정

UI가 가지고 있는 상태를 ‘추상화’하여 그것을 모듈화하는 것으로 Headless를 구현할 수 있다. 스타일은 걷어내고 이 UI가 내포하고 있는 상태는 무엇이며 이 상태를 관리하기 위한 적절한 자료구조는 무엇인지 고민하는 것이 우선이다. 그리고 그 상태를 제어할 수 있는 최소한의 API만을 제공한다.

1) 가장 작은 형태의 DataTable 생각해보기

• DataTable은 dataSource 그를 표현할 속성(column)을 기준으로 data를 배치한 테이블 이다.
• 즉 dataSource를 주어진 속성(tableModel)에 맞게 배치해야한다.

graph LR
  id1[DataSource, TableModel] -- 정의된 모델에 맞게 source를 배치 --> DataTable

• filter, search, sort는 부가 기능
• DataTable 자체가 filter/search를 위한 UI 까지 가지는 것이 아니라, filtering을 위해 정해진 인터페이스를 오픈하고, 이를 처리하는 로직만을 DataTable이 가지고 있어 Filter/Search 컴포넌트와의 의존성을 최대한 줄이기
• filtering은 로직 filterQuery를 prop으로 받아 적용한다.
• ex.{ category: ‘곡류’ , id: [1,2,3] } : 곡류 중에서 id가 1,2,3 인 Product만을 렌더링

graph LR
  id1[DataSource, TableModel] -- filterQuery --> id2[filtering]-- filtered source를 배치 --> DataTable

 

2) TableModel이 가지고 있는 인터페이스는 무엇이어야 할까

interface TableModel {
	label: stirng // header에서 보여줄 label값
	accesor: string // key of DataSource
	header?: { render: ({headerProps}) => <CustomElment />} 
	cell? : { render: ({cellProps}) => <CustomElment />}
}[]

• DataTable 은 dataSource를 tableModel 에 맞게 배치된 2x2 형태의 Table 엘리먼트로 정의하였다.
accessor
Cell 에 보여주기 위한 data를 찾기 위한 key 값으로, 반드시 DataSource의 포함되어 있는 key값이어야만 한다.
render
 
headerProps cellProps
custom 값을 표현하기 위한 함수로 필요 위치에 따라 header, cell 프로퍼티의 함수로 정의할 수 있다. 5000 이라는 price를 5,000원 으로 파싱하거나, 경우에 따라 Element형태로 가공할 수 있어야 한다.
render함수에서의 props 값들은 구현단에서 지정해줄 수 있으며, 일반적으로 각 header와 cell에서의 value를 포함하고 있는 useDataTable hook 에서 내려주는 값으로 지정한다.

tableModel 구현체 ( 화살표 눌러 펼치기 )

• TableModel

const productTableModel = [
		{
      label: "대표 이미지",
      accessor: "imageUrl",
      header: { render: ({ headerProps }) => <div>썸네일</div> },
      cell: {
        render: ({ cellProps }) => ( <Image src={cellProps.value}/> ),
      },
    },
    {
      label: "가격",
      accessor: "price",
      cell: { render: ({ cellProps }) => `${cellProps.value.toLocaleString("ko-KR")}원` },
    }, ...]

• 구현부 ProductDataTable
• headerGroups와 rowModel에서는 현제 Cell의 value정보를 포함하고 있다.

	...
	const { headerGroups, rowModel } = useDataTable<Product>({
	    dataSource,
	    tableModel,
	  });
	...
	return(
		 <THead>
        <TRow>
          {headerGroups.map((header) => {
            return <THeadCell>{header.render({ headerProps: header })}</HeadCell>;
          })}
        </TRow>
      </THead>
      <TBody>
        {rowModel.map((row) => (
          <TRow key={row.id}>
            {row.cells.map((cell) => {
              return <TCell>{cell.render({ cellProps: cell })}</Cell>;
            })}
          </TRow>
        ))}
      </TBody>
	)

3) 부가 기능과 DataTable을 분리하여 의존성 줄이기

[1. filterQuery를 통한 Filtering]

따라서 DataTable 컴포넌트와 Filter/Search 컴포넌트가 분리되어 있고, 두 컴포넌트가 queryParams를 통해 약한 연결 관계를 가지는 구조로 설계하였다. 1) Filter/Search 컴포넌트는 filter 조건을 약속된 형식의 queryString으로 표현하는 역할을 담당

2) DataTable은 현재 url로 부터 queryParameter를 읽어와 해당하는 data를 표현해주는 역할을 담당 이를 통해 UI결합도를 낮출 수 있고, 각 컴포넌트의 역할과 책임을 명확하게 구분할 수 있다.

graph LR
  id1[Category, Search] -- 약속된 queryParameter 형식 --> id2[queryString]-- filterQuery를 받아 filtering 적용 --> id3[DataTable]

결과 및 한계점

결과

• CodeSandbox Demo (Github 보기)

한계점