리액트에서 제공하는 React.Children 유틸리티

https://www.reactenlightenment.com/basic-react-components/6.8.html

6.7 Accessing Children Components/Nodes · React Enlightenment [DRAFT]

https://reactjs.org/docs/react-api.html#reactchildren

이번에 컨테이너 컴포넌트를 개발하는데, children 프로퍼티로 들어오는 엘리먼트 타입을 확인해야 하는 경우가 생겼다. 그래서 처음으로 리액트에서 제공하는 React.Children 유틸리티를 사용해봤다. 사실 유틸리티 사용 안 하고 Array.from() 등을 사용해서 배열로 변환해도 된다. 그렇지만 라이브러리에서 제공하는 이유가 있지 않을까? (내부 코드) 손수 변환했을 때와 비교해서 예외 케이스에 대한 처리가 잘 돼있을 거라 생각해 이를 채택했다.

아무래도 컴포넌트 라이브러리를 만들다 보니, 바운더리가 확정된 서비스를 만들 때와는 다르게 생각하는 경우가 많아졌다. 같이 개발하는 동료가 '사람들이 어떤 것을 넣을지 모르는 게 제일 걱정이다'라고 했는데 이런 맥락에서 한 이야기 같다. 사실 그런데 이런 것도 서비스 개발할 때 얼마든지 알아보고 적용할 수 있었는데, 케이스가 딱 정해져 있다 보니 이렇게 까지 생각 안 하고 그냥 주어진 케이스에 맞춰서 개발하는 경우가 많았다. if가 애초에 기획 단계에서 다 걸러지므로 분기를 태울 필요가 없어지는 것이다.

antd 같은 라이브러리는 레이아웃 컴포넌트 안에 헤더와 푸터를 전달할 때 그 구성을 자유롭게 해서 children으로 전달한다. 사실 antd 같이 오픈 소스로 공개해버리면 그렇게 해야 할 것이다. 하지만 사내용 라이브러리의 경우에는 구성원들의 동의 하에 강제로 제약을 줄 수 있다. (아 생각해보니 나중에 퍼블릭으로 전환한다고 하면 너무 사내용으로 개발한 부분들을 수정해야겠네?!)

엄청난 자유도를 원하는 개발자라면 규칙이 이미 다 정해져 있어서 싫어하겠지만, 대부분의 사람들은 실험보다는 주어진 기능을 마감 시간에 맞춰 개발하고 퇴근하고 싶은 마음이 간절하지 않을까? 그래서 prettier 같이 opinionated(독단적인, 독선적인) 콘셉트의 툴도 분명 니즈가 많다.