Headless 컴포넌트들의 스타일 파일 위치 관련 논의

[mina-gwak]

cos-ui 프로젝트 세팅을 하던 중에 Headless 컴포넌트들에 스타일을 입힌 파일을 어떤 식으로 두고 사용할지 고민이 되어서 의견을 나눠보고자 디스커션을 올리게 됐습니다!

src
├─ components
│   ├── Avatar
│   ├── AvatarGroup
│   ├── ClickAway
│   ├── Dropdown
│   ├── FlexBox
│   ├── Paper
│   ├── RadioGroup
│   ├── Slider
│   ├── Tab
│   ├── Text
│   └── TextField
└─  index.ts

현재 @cos-ui/react는 이런 구조로 되어있고 index.ts 파일에서 각 폴더 안에 있는 index 파일을 가져와 export 해주고 있습니다.

// index.ts
export { default as ClickAway } from '@components/ClickAway';
export { default as Dropdown } from '@components/Dropdown';

이런 상황에서 Headless 요소들을 스타일링한 컴포넌트들을 어떻게 할 수 있을지 생각해보면 3가지 정도가 떠오르더라구요.

1. @cos-ui/react 패키지 내부에 두기
2. cos-ui 내에서 다른 패키지로 분리하기
3. 사용하는 쪽에 두기 (기존 프로젝트)

같은 패키지 내에 둘 경우에는 저희 프로젝트에서 사용할 때에는 스타일링된 요소만을 사용할 것이기 때문에 스타일링을 한 컴포넌트가 아닌 기본 기능만 있는 Headless 컴포넌트들은 export해도 쓸 일이 없을 것 같아요. 그렇다고 스타일링된 파일만 내보내는 건 또 좀 그렇지 않나 싶은 생각이 듭니다.

그리고 현재 Tab 같은 경우 Headless 컴포넌트에 스타일을 입힌 파일이 2개 존재하는데요, 이렇게 하나의 컴포넌트에 여러 개의 스타일링된 파일이 존재할 때 네이밍을 어떻게 해야할지도 좀 고민이 되는 부분인 것 같습니다. 단순히 StyledTabA 이런 식으로 이름을 붙이거나 어떤 탭인지 좀 더 명확하게 드러날 수 있는 이름을 붙일 수도 있을 것 같은데, 후자의 경우 구체적으로 이름이 붙여지게 되면 범용적으로 쓰인다기보단 저희 프로젝트에 종속적인 쪽에 좀 더 가까워질 수도 있지 않을까 싶어요.

또 저희 프로젝트에 이렇게까지 구현될 요소가 있을까 싶긴 한데, 지속 가능한 성장과 컴포넌트 영상의 예시를 보면 Select 컴포넌트를 사용하고 있지만 일반적인 Select와 좀 다른 형태이고, 이름뿐만 아니라 컴포넌트의 구성 자체도 도메인에 종속적인 느낌이라 Headless 컴포넌트와 같이 두기엔 성격이 좀 다른 것 같다는 생각이 들었습니다.

cos-ui 내에서 다른 패키지로 분리하게 되면 비슷한 성격을 가지는 컴포넌트들끼리 묶이는 느낌이라 개인적으로 좀 더 나은 방법인 것 같다는 생각이 들긴 해요. 근데 이렇게 분리했을 때의 불편한 점이라고 하면 (별도의 패키지로 분리하지 않고 cos-ui만 존재하는 현재의 상황도 포함) Co-Studo-front, @cos-ui/react, @cos-ui/playground-react 에서 theme, fonts 같은 파일이나 ESLint 룰 같은 것들이 모든 패키지, 레포에서 공통적으로 사용되는 것들인데, 이런 파일에서 수정이 발생하면 모든 패키지에 있는 파일을 수정해서 동기화를 시켜줘야한다는 것입니다. 모든 패키지가 연동이 되어있거나 해서 자동으로 이루어지는 게 아니다보니 항상 동일하게 유지된다는 보장이 없다는 점, 일일이 수정하기 번거롭다는 점이 문제인 것 같아요. 이런 상황에서 패키지가 하나 더 늘어나게 되면 번거로움도 커지고 신경 써야하는 부분도 많아지지 않을까 싶어서 고민이 되는 것 같습니다.

마지막으로 Headless 요소를 사용하는 프로젝트인 Co-Studo-front 에서 관리할 수도 있을 것 같은데요. 사용하는 쪽에서 관리하는 것이다보니 이름이나 컴포넌트 구성이 종속적이어도 상관없고, 패키지를 새롭게 추가하는 것도 아니라 현재 상황에서 번거로운 부분이 늘어나지 않는다는 점에서 저는 이 방식이 제일 낫지 않나 싶은 생각이 들었습니다.

지금까지 고민했던 부분은 이 정도인데, 제가 고려하지 못했던 게 있거나 더 좋은 방안이 있을 수 있으니 자유롭게 의견 주시면 감사할 것 같아요!!

@jindonyy @hemudi @healtheloper

[jindonyy]

고민을 많이 한거 같네요 제이미!
음.. 우선 저는 패키지로 분리한다고 했을 때 headless만 당연히 분리할거라고 생각했어요. 왜냐하면 저희 프로젝트에 사용할 스타일 컴포넌트는 당연히 저희 프로젝트에서 관리하는게 맞다고 생각했기 때문이예요! 범용적인 컴포넌트가 아니니까? 그래서 저는 3번이 맞다고 생각합니다!

그리고 현재 Tab 같은 경우 Headless 컴포넌트에 스타일을 입힌 파일이 2개 존재하는데요, 이렇게 하나의 컴포넌트에 여러 개의 스타일링된 파일이 존재할 때 네이밍을 어떻게 해야할지도 좀 고민이 되는 부분인 것 같습니다.

이 부분은 저도 네이밍을 변경해야한다고 생각해요. 너무 당연한거지만 A, B로 나눠져있길래 뭘 나타낸건지 알 수 없어서 테스트용..으로 만들어둔거라 생각했습니다 ^_ㅠ
그래서 StyledTabBottomLine, StyledTabGreyColor 등으로 활성화될 때 어떻게 바뀌는지 적으면 어떨까 싶네요!
근데 디자인 파일에서 A 스타일의 탭을 못찾겠던데,, 혹시 어디에 있는 탭인가요?ㅠㅠ

[mina-gwak]

음.. 우선 저는 패키지로 분리한다고 했을 때 headless만 당연히 분리할거라고 생각했어요.

아하 저는 전에 스타일 파일도 함께 분리하자고 얘기를 들었던 것 같아서 앞의 선택지도 함께 고려해서 고민했던 것 같아요!

너무 당연한거지만 A, B로 나눠져있길래 뭘 나타낸건지 알 수 없어서 테스트용..으로 만들어둔거라 생각했습니다 ^_ㅠ

이 부분은 처음엔 테스트 용도로 만든 게 맞습니다! 초반에 만들기도 해서 임시로 해둔 거기도 했고, 저희가 스타일 파일을 XX.styled.ts 이런 식으로 하고 있는데 각각 다른 스타일을 가지는 컴포넌트를 만들려니까 이름을 어떻게 해야할지 몰라서 일단 a, b로 해뒀던 거였어요!

근데 디자인 파일에서 A 스타일의 탭을 못찾겠던데,, 혹시 어디에 있는 탭인가요?ㅠㅠ

이 부분은 메인 페이지에서 모집중인 스터디 옆의 전체 / 신규 / 인기 이 부분을 생각하고 만든 거였습니다!

[healtheloper]

그리고 현재 Tab 같은 경우 Headless 컴포넌트에 스타일을 입힌 파일이 2개 존재하는데요, 이렇게 하나의 컴포넌트에 여러 개의 스타일링된 파일이 존재할 때 네이밍을 어떻게 해야할지도 좀 고민이 되는 부분인 것 같습니다.

cos-ui 를 디자인이 입혀진 것도 제공한다고 생각하면, 하나만 제공하는 게 맞는 것 같고, 저희 프로젝트에서는 두 가지 형태의 탭을 사용하니

1. 제공된 하나를 가져와 사용 + 다른 하나는 CoStudo 에서 Headless 컴포넌트를 가져와 스타일 입혀 사용
2. 스타일이 입혀 제공되는 것은 프로젝트와 무관하게 무난한걸로 제공 + CoStudo 에서 Headless 컴포넌트를 가져와 두 개의 탭을 만들어 사용

의 두 가지 방법이 떠오릅니다. 저는 어차피 제공할 거 전자의 방식으로 해도 좋다고 생각해요

저는 제이미가 말씀해주신 3개의 방식 중 2번 방식을 처음에 생각했었는데요, 말씀해주신 fonts 같은 부분을 cos-ui 로 완전히 위임하는 방향으로, 기반은 CoStudo 프로젝트에 종속적인 것으로 가는걸 생각했던 것 같아요. 그럼 관리는 cos-ui 에서만 하면 되지 않을까요?

[healtheloper]

다른 프로젝트라고 하면 그럴 가능성이 높고, 저희가 해당 컴포넌트를 참고할 땐 당연히 Primitive 를 가져다 쓸 가능성이 높아요.

아 이 말은 다른 프로젝트의 상황에서 얘기하는 것 이었습니다ㅋㅋㅋ

말이 조금 애매한데 mui, headlessui 로 보자면 mui 쪽에 가깝다는 말로 이해해도 될까요?

궁극적으로 CoStudo 에서는 cos-ui/react 를 사용하게 될텐데 그건 mui 에 가깝고, 다른 곳에서 사용할(?) primitive 는 headless 인거죵

적어주신 예시 상황이 맞고, 이젠 StyledTab 이라는 이름으로 제공해주기 보다 아예 Tab 이라고 제공해줘도 될 것 같아요!

[mina-gwak]

이해했습니다! 그런 용도라면 playground를 그대로 둬도 괜찮을 것 같네요. 도니까지 동의하시면 이런 방향으로 진행해도 좋을 것 같아요!

그렇게 된다고 하면 primitive 쪽에서 다른 네이밍을 사용해야 할 것 같네요. 이 부분도 추가적으로 이야기해봐야 할 것 같은데 여기서 논의하는 게 좋을까요?

[healtheloper]

ComponentPrimitive 정도로 해도 되지 않을까요?
아니면 어차피 분리되어있으니 안해줘도 될까요? 투표로 정해도 괜찮을 것 같아요 ㅎㅎ
이름(Primitive, Base, ...), 컴포넌트 이름끝에 붙일지말지..

[jindonyy]

뒤늦게 봐서 죄송합니다ㅠㅠ
근데 playground는 꼭 필요한걸까요..? 예시가 있는건 좋은데 지금 저희가 storybook으로 예시를 확인하는거처럼 사용하면 되는거 아닌가..? 라는 생각이 문득 들어서 질문드립니다!

혹시 스토리북을 깔아야지만 볼 수 있으니까 그런걸까요 ㅇㅅㅇ? 그럼 배포한 링크를 제공하면 되지 않을까 싶은..?

[healtheloper]

UI 라이브러리를 소개하는걸 스토리북으로 대체한 라이브러리 몇개를 본적 있는데, 좀 불친절한?? 불편한? 느낌을 받긴 했었어서 playground 같은 문서가 별도로 있으면 좋겠다고 생각했어요.

다른 분들이 만드신 코드를 사용할 때 레포지토리의 스토리북 코드를 들어가서 인터페이스를 확인하기 보다 그런 사용법을 모아두면 더 편리할 거라 생각했고,
만약 hook 을 제공하는 컴포넌트라면 (form 과 같은) 스토리북 과 코드 만 봐서 쉽게 이해할 수 있을까? 라는 생각도 있긴 했었고..

컴포넌트를 만들어서 어떻게 사용하면 좋은지, 어떻게 쓰는지 문서화 하는 것도 사용자를 고려해보는 경험(?) 이라 생각해서 필요성을 느꼈었습니다

[hemudi]

ㅎㅎ 의견을 남기기 조금 늦은 감이 있는 것 같지만...

저도 사실 처음에 Headless 컴포넌트 자체만 별도의 패키지로 분리하는줄 알았어요. 스타일은 제외하고!
그러다 파크께서 디자인 시스템 영상을 공유해주시면서 저희가 분리할 라이브러리가 영상에 나왔던 extension 라이브러리에 가깝다고 하셨어서 그때 처음 스타일도 같이 분리하는거구나 하고 깨달았어요...

그런데 그때 당시에 저도 스타일은 너무 CoStudo 프로젝트에 종속적이지 않나? 분리한다면 fonts, colors 같은 파일도 같이 옮겨야 할텐데 그걸 굳이 분리할 필요가 있나? 어차피 Headless 만 따로 분리해서 그걸 가져와 그냥 스타일을 입혀 사용해도 괜찮을 것 같은데 싶은 생각이 들었는데
관점을 바꿔서 현재 각 컴포넌트에 입히는 스타일이 CoStudo 프로젝트의 스타일이 아닌 cos-ui 패키지에서 제공하는 기본 스타일들이고
저희 CoStudo 프로젝트가 그 스타일에 맞춰 개발하는거라 생각하니까 같이 분리해도 괜찮겠다는 생각을 했었어요!
(material ui 의 스타일 입혀진 컴포넌트를 그대로 가져다 쓰는 것 처럼...?)
스타일도 함께 제공해준다면 추가적인 스타일 커스텀 없이 그냥 가져다 사용 할 수 있다는 장점도 있으니까요.

그래서 분리를 한다하면 저는 좀 번거롭더라도 두번째 방식(cos-ui 내에서 다른 패키지로 분리) 이 좋을 것 같습니다.
각 패키지마다 조금씩 중복되는 설정 값들이 있고 그에 따른 관리의 어려움이 있다 하더라도 역할에 맞게 명확히 분리를 해야
스타일이 필요 없는 경우엔 Headless 컴포넌트가 들어있는 패키지 자체만 가져와 사용 하는 등의 패키지 분리의 장점을 활용할 수 있을 것 같아요.

그리고 이건 개인적이고 주관적인 생각인데 Co-Studo-front 를 cos-ui 로 별도로 분리를 하는 시점에서 서로 독립적인 시스템...?이 되었으니 각 시스템 끼리의 설정값이나 코드의 일관성은 덜 고려해도 괜찮지 않을까 싶어요.
저희가 지금 동시에 개발해서 ESLint, colors나 fonts 등의 중복 설정, 중복 코드가 신경이 쓰이지만 결과적으로 보면 cos-ui 랑 Co-Studo-front는 별도의 시스템이고 저희는 Co-Studo-front 프로젝트를 개발하면서 그냥 cos-ui 라이브러리를 가져다 사용하는게 되는건데 cos-ui 내의 코드와 Co-Studo-front 내의 코드의 중복을 고려할 필요가 있나? 싶네요.

그래서 각각의 레포에 맞는 린트 파일이나 스타일(fonts, colors) 파일들이 존재할 수 있다 싶고,
코드의 일관성이나 중복등은 각 시스템 내에서만 고려해도 괜찮을 것 같아요!

[mina-gwak]

말씀하신 것처럼 관점의 차이일 수 있겠네요! 저희가 만드는 cos-ui를 mui처럼 스타일링된 요소들을 제공하는 UI 라이브러리로 볼 것인지, 아니면 headlessui처럼 Headless 컴포넌트를 제공하는 라이브러리로 볼 것인지에 따라 다를 것 같아요. 전자의 경우 스타일링이 입혀진 요소들을 가져다 쓰게 될 거고, 후자의 경우에는 Headless 컴포넌트를 가져와 저희 프로젝트에서 구현해서 쓰는 방식이 될테니까요. 파크의 코멘트에서 남긴 것처럼 playground와 스타일링된 요소를 제공하는 패키지가 비슷한 느낌이 있어서 하나만 남기는 게 좋지 않을까 싶은데 어떻게 생각하시나요? 만약 괜찮으시다면 cos-ui를 mui, headlessui와 같은 방식 중에 어떤 방향으로 가져갈지만 저희끼리 논의해서 확실히 정하면 패키지는 자동으로 정리가 되지 않을까 싶어요!

Co-Studo-front 를 cos-ui 로 별도로 분리를 하는 시점에서 서로 독립적인 시스템...?이 되었으니 각 시스템 끼리의 설정값이나 코드의 일관성은 덜 고려해도 괜찮지 않을까 싶어요.

동의합니다! 별도의 레포지만 저희가 개발하고 있는 거기도 하고 해서 그렇게 생각했던 것 같아요. 레포 내에 있는 것들만 동일하게 가져가도 문제 없을 것 같네요 👍

[hemudi]

playground와 스타일링된 요소를 제공하는 패키지가 비슷한 느낌이 있어서 하나만 남기는 게 좋지 않을까 싶은데 어떻게 생각하시나요?

괜찮을 것 같네요!
제이미께서 생각하시기에 분리하는데 큰 의미가 없다고 생각하시면 그 의견에 따르겠습니다! ^_^)b

cos-ui를 mui, headlessui와 같은 방식 중에 어떤 방향으로 가져갈지

제가 생각하던 방향은 mui 쪽이 가까웠던 것 같아요!
이왕 스타일을 구현하는 김에 예시로만 남겨두는 것보다 사용자의 선택에 따라 사용 할 수 있게 함께 제공해주면 좋지 않을까 싶은 생각이 드네요! ^//^)>

[jindonyy]

11/3 토론 결과

• 같은 레포에서 관리, 패키지(폴더)는 분리
  • Dony: 저희 프로젝트에 종속적인 디자인 시스템인데 굳이 배포할 필요가 있을까?
  • Park: mui 도 구글에서 사용하는 디자인 시스템이니 다른 곳에서 커스텀해서 사용해도 괜찮을 듯하다.
  • Jamie: 디자인 시스템 컴포넌트와 headless 컴포넌트는 성격이 다른데 하나의 레포에 둬도 괜찮을지 고민.
  • Dony: headless만 쓰고 싶으면 그 부분만, 디자인 시스템 컴포넌트도 쓰고 싶으면 함께 설치해서 사용하면 되니까 같이 있어도 될 듯 하다. 어쨌든 저희 프로젝트에서 만든 컴포넌트이니?
• 네이밍은 Primitive 든 아니든 동일하게 해서 import 해올 때 원하는 이름으로 변경해서 사용하도록.

  // Tab.tsx
  import { Tab as TabBase } from 'cos-ui/primitive'
  
  const Tab = styled(TabBase)`
    ....
  `;