Feat: RadioButton 컴포넌트 구현

[이우재]

💎 개발할 기능

• 아래 4가지 상태에 대한 스타일 정의하기
  • Normal
  • Hover
  • Active
  • Disabled
• Disabled에 사용할 회색 + Primary로 사용할 단색
  • 이 Primary color는 theme의 primary를 사용하되 설정 가능한 것으로 하고 싶어요
  • CSSAttribute['color'] 이런 타입이 있던걸로 아는데 그걸 사용해서 받으면 될 것 같아요
• 선택된 라디오버튼을 원모양 대신 체크표시로 하면 이쁠 것 같은데 구현하기 피곤할 것 같아요.. 아니 근데 이쁠까요?

이게 각자가 디자인을 알아서 구현하다보니까 통일성이 있을지 잘 모르겠어요. 갑자기 그런 걱정이 들었어요

기존 작업내용을 폐기하고 다시 만들기로 했어요. 댓글을 참고해 주세요!

📖 참고 사항

[hodun]

디자인을 한번 정리해볼게요

[이우재]

03/28 추가

아무래도 커스텀을 생각해서 너무 불필요한 코드를 주렁주렁 달고 있어서, 기존 코드를 폐기하고 재작업할 것 같아요.
기본 사용법 자체는 기존 방식이 그렇게 나쁜 것 같지 않아서 대부분 유지할 것 같아요.

<RadioButton id="se030" name="leader" value="김세영" />

• idle, hover, active, disabled 4가지 상태
• size(지름), color 정도의 props 받기
• 관련 접근성 속성이 있는지 조사하기
• 라디오 버튼을 코드에서 어떻게 참조 가능하게 만들 것인지?
  • forwardRef로 input에 대한 ref를 제공해야 할까?
• 커스텀??
  • 이전의 커스텀 플래그까지 지원하는건 일단 보류에요. 만약 한다면 위 4가지 상태를 나타내는 className 내지는 data Attribute를 통해 표현할 수 있도록 하는 방식을 생각중인데.. 여전히 잘 모르겠어요.
  • 그럼에도 불구하고 커스텀에 대해 고민하는 이유는 아래와 같은 usecase들 때문이에요.
    
    
    

이런 Select와 Radio 사이 어딘가에 있는 녀석들을 개발자가 cds를 이용해 어떻게 구현하면 좋을까? 하는 고민에 빠졌어요. 의견 주시면 너무 감사해요 ㅠㅠ

[se]

도움이 될지 모르겠지만 라디오가 사용되는 인터페이스가 어떻게 있으면 좋을지 대충 생각해봤어요.

<Radio.Group name="leader">
  <Radio.Input value="" status="disabled" />
  <Radio.Input value="" />
  <Radio.Input value="" />
  <Radio.Input value="" defaultSelected={true} />
</Radio.Group>

그리고 가져오신 레퍼런스들처럼 기존의 형태에서 벗어난 형태로도 정말 많이 쓰게될텐데, 이런 경우 상태에 따른 스타일링은 개발자에게 맡겨야 할 것 같아요. 상태에 따라서 className을 바꿔주는게 가장 괜찮을 것 같아요.

마지막 사진을 컴포넌트로 작성해보면 저는 이렇게 쓰고싶을 것 같아요. 컴포넌트명은 생각이 안나서 그냥 Input으로 했어요. children 여부에 따라서 내부로직 다르게 만들어달라고하면 오바에요?

<Radio.Group name="download">

  <Radio.Input value="10">
    <DownloadCard cnt={10} />
  </Radio.Input>

  <Radio.Input value="30">
    <DownloadCard cnt={30} />
  </Radio.Input>

</Radio.Group>

라디오 버튼을 코드에서 어떻게 참조 가능하게 만들 것인지?

마지막으로 이 부분은 왜 필요한지 궁금해요! 기존에도 감춰진 input 태그가 있었던 것 같은데, 비슷하게 숨겨진 input을 통해서 form에 필요한 정보를 관리할 수 있지 않나요? 라디오버튼은 개발자가 조작한다기보다는 사용자 입력을 받는 요소라고 생각돼서요.

[이우재]

글을 보고 그룹의 존재를 떠올렸어요. name 프로퍼티로 그룹핑이 가능하긴 하지만 fieldset같은걸 사용하고 싶은 경우도 있으니 만드는게 좋을까요..? 근데 또 이걸 위해서 컴파운드 컴포넌트 패턴을 적용하는건 또 뭔가 망설여져요.

커스텀은 Material UI, Chakra UI의 문서를 보니 제각각 구현방식이 다르더라구요. children으로 구현하는 것도 괜찮을 것 같고, 사용하는 입장에서 어떻게 쓰는게 제일 편할지 고민하다가, 이번 구현에는 커스텀 빼기로 했어요(?). 너무 머리아파요..

라디오 버튼을 코드에서 어떻게 참조 가능하게 만들 것인지?

마지막으로 이 부분은 왜 필요한지 궁금해요! 기존에도 감춰진 input 태그가 있었던 것 같은데, 비슷하게 숨겨진 input을 통해서 form에 필요한 정보를 관리할 수 있지 않나요? 라디오버튼은 개발자가 조작한다기보다는 사용자 입력을 받는 요소라고 생각돼서요.

저는 모든 input이 form에만 사용되는게 아니니까 라디오도 분명 그런 경우가 있을 거라 생각했어요. textInput도 ref를 사용해 값에 접근하는 경우가 있듯이요. 이런 경우에 ref를 지정할 수 있도록 해주지 않으면 사용이 불가능할 것 같아요.
사실 부캠 학습스프린트때 (리액트는 아니고) 직접 radio input에 접근했던 기억이 있어서 이런 내용을 썼는데, 생각해 보니 일반적이지 않으니 그냥 생략할까.. 고민중이에요. 의견 고마워요!

[이우재]

PR의 이 댓글에서 이어지는 생각이에요. 원래 여기 정리하는게 맞는데 저 댓글은 PR 다시 열려고 쓰던거라 저기에 가있어요 혼란스럽게 만들어서 죄송해요 ㅋㅋ..

이렇게 하면 label 태그로 처리하던 input-click 동작을 input 태그가 직접 처리해서 접근성 측면에서 이점을 얻을 수 있어요.

제가 잘못 생각했어요. 지금 브랜치에 올라가있는 스토리에서 실제 input 버튼에 pointer-events: none;이 달려 있어서 클릭 이벤트가 작동하지 않아요. 그럼에도 작동하는 이유는 label로 감싸져 있기 때문이에요..
왜 저 속성을 달았냐면 버튼이 커스텀 가능해야 하기 때문에 hover, active를 포함한 css 스타일링을 실제 투명 input 태그 아래로 겹쳐 있는 버튼 컴포넌트에 주고 싶어서 이렇게 했는데 오늘 뭔가 수정하면서 이 상황을 발견했어요.

그 외에 pointer-events:none; 속성은 모든 유저 선택 동작을 막기 때문에 접근성에 문제를 일으킬 수 있다는 의견을 봐서, 지금 상태가 건강하지 않다는 생각을 했어요. 그리고 세영님이 테스트해보신대로 이미 접근성에 문제가 있는 것 같아요(?)

여기까지 생각을 하고 나니까 차라리 그럼 처음으로 돌아가서 label로 감싼 버튼을 만들고, 라벨 역할을 하는 텍스트나 기타 요소들을 children으로 받으면 어떨까? 하는 생각이 들어 슬랙에서의 제안을 드린거에요. 맨~~~~~처음 결과물과 비슷하지만, 차이가 있다면 사용자가 라벨을 사용해야 하는 부분(버튼 옆에 이름을 달아주는 것)까지도 책임을 지자는 거에요. 이렇게 하면 코드는 좀 더러울지도 모르지만 buttonPosition같은 props로 children(라벨)과 버튼의 위치 관계를 조절하도록 하고.. 어느 정도 제가 저번에 제시했던 라디오버튼이지만 라디오버튼처럼 생기지 않은 것들에 대한 핸들링도 가능할 것 같아요(추상적 생각) 제일 큰 문제는 이렇게 하는게 DX 측면에서 괜찮은 수준인가 하는거에요.

그리고 라디오 그룹 관련해서는 지금 고민하고 있는게, 라디오그룹을 사용하는 경우 / 사용하지 않는 경우를 둘 다 지원해야 하지는 않을까 하는 걱정 때문에, context를 가져오려고 시도하고 + 안되면 분기해서 기본 로직을 갖도록 하기 이게 가능한지 + 괜찮은지 생각 중이에요.

다 생각 중이기만 하네요 아 ㅋㅋ..