컴파운드 패턴 모달 적용기

Compound 합성.

하나의 컴포넌트를 잘게 쪼개 레고 블럭처럼 조립해 쓴다니, 이 얼마나 리액트 컨셉에 잘 맞아떨어지는 패턴이란 말인가

 

내가 컴파운드 패턴을 공부하기 시작한 데에는 몇 가지 이유가 있었다.

 

첫째, 중복된 코드들로 인해 난잡해진 팀 프로젝트의 코드 수를 대폭 줄일 필요가 있었으며,

둘째, 중구난방으로 쓰이고 있는 모달들을 통합할 필요가 있었고,

셋째, 팀원들의 부탁도 있었던 데다가,

넷째, 현업에서 많이 쓰이는 패턴이라는 소리를 어디선가 들은 것에 더해,

다섯째, 클린해보였다...!

 

컴파운드 컴포넌트 이렇게 쓰는 거 맞음?

 

나는 바로 코딩에 들어갔다.

 

뚝딱!

 

 

아주 기본적인 컴파운트 패턴의 모달 컴포넌트가 완성되었다.(거의 이틀이 걸렸다.)

 

notClose를 주냐 안 주냐에 따라 배경을 눌렀을 때 꺼지는 유무가 결정될 것이고,

BackDrop을 빼면 모달창을 띄운 상태로도 '눌러지냐' 버튼을 누를 수 있을 것이다.

또, XYcoordinate의 props 값에 따라 모달창이 뜨는 위치도 결정될 것이다.

 

괜찮아 보인다. 나름 범용성 있어 보이는, 만족스러운 결과물인 것 같다.

 

그러나 이걸 프로젝트로 들고 가니 말이 달라졌다.

 

props 드릴링!!!

 

 

모달이 필요할 때마다 부모 컴포넌트에 모달 컴포넌트들을 전부 붙일 순 없는 노릇이었기에, 모달을 먼저 조립했고, 트리거를 일으켜야할 컴포넌트를 감싼 뒤, 내용물이 되어야 할 컴포넌트를 모달 컴포넌트 사이에 넣어주었다.

 

그러나 이처럼 모든 것들을 컴포넌트화 한 경우라면 props를 내려줄 때 A-B-C에서 B를 의미없이 거쳐야만 하는 문제가 생기게 된다.

하나 정도야 싶지만 만약 모달에 모달을 띄우는 경우라면 어떨까?

A-B-C-D-E구조가 될 것이고 B와 D에서는 프리패스가 발생한다.

 

좋은 구조는 아닌 것으로 보인다.

그렇다면 어떻게 써야 잘 쓰는 것일까?

 

내가 가장 먼저 떠올린 방법은 뎁스를 줄이기 보단 전역 상태관리 라이브러리를 사용하는 것이었다.

 

'redux로 C와 E에서 빼다가 쓰면 되겠네.'

 

컴포넌트를 길게 풀어놓는 것은 마음에 안들었으며, 이것이 간단하게 문제를 해결해 줄 방법으로 보였다.

 

그러나 문득 한 생각이 발목을 잡았다.

 

'리덕스로 만들어 놨는데 리코일이나 다른 라이브러리로 바꾸자고 한다면 그거 다 수정하고 있을 거냐. 너무 비효율적이다. 리액트랑 자바스크립트만 써서 사용할 수 있는 모달창으로 새로 하나 만들어달라.'

 

팀원의 했었던 말.

 

그리고 이건 기존의 redux로 관리되던 모달을 폐기하고 컴파운드 패턴의 모달을 만들게 된 이유이기도 했다.

그런데 기껏 새로 만들어 놓고 다시 전역 상태 라이브러리에 의존하게 된다면 결국 만든 의미가 퇴색되지 않는가.

 

나는 다른 방법을 강구했다.

 

그래서 떠올린 것은 모달을 만들 때 썼었던 useContext.

props 리렌더링의 문제에 예민할 수 있는 방법이겠지만, 모달에서는 크게 문제가 되지 않을 것으로 생각됐다.

 

 

위와 같이 redux를 안 쓰고도 쓴 것과 비슷한 결과가 되었다.

 

props 드릴링의 지옥에서 벗어난 듯 보인다.

 

그런데도 나는 찜찜했다.

 

'그럼 모달창이 필요한 곳마다 전부 저 작업을 해줘야 하는 건가?'

 

비효율적이다. 너무도 비효율적이다!!!

코드의 반복을 줄이고 간결하게 하자고 한 게 어째서 이렇게 되어버린 것일까.

해치웠나?

 

그러다가 문득 나는 조금 근본적인 의문이 떠올랐다.

props로 왜 골머리를 앓고 있지?

그래, 고작 모달 하나 만드는 건데 만들 때마다 컴포넌트를 줄줄이 만들어야 하는 건가?

 

어쩌면 나는 너무 컴포넌트를 쪼개는 것에 정신을 뺏겨 중요한 것을 잊고 있었는지도 모른다.

바로 편의성과 효율 말이다.

 

너무 먼 길을 돌아온 것 같다.

 

그래서 나는 컴포넌트를 풀고 뎁스를 하나 없애기로 했다.

 

훨씬 직관적이고 사용하기 간편해 보인다.

 

그러나 나는 여전히 모달이 필요한 곳에 저 컴파운드 모달들을 계속해서 반복적으로 붙여야 할 것에 불만을 느꼈다.

 

모달의 규격화

 

좀 더 효율적인 방법이 있진 않을까 고민에 빠졌다.

 

그냥 모달 하나 조립해 놓고 모든 곳에서 돌려쓸 순 없는 걸까?

 

나는 바로 모달을 조립해 컴포넌트로 빼서 여러 곳에 돌려쓸 수 있도록 하는 작업에 돌입했다.

 

 

위와 같은 형식으로 바탕을 눌러도 모달이 닫히는 것, 닫히지 않는 것, 중앙에 위치하는 것, 아래 위치하는 것 등 나눠서 모달을 조립해 규격화시켰다.

필요하다면 그에 맞게 새로 조립해서 만들면 되니 컴파운드의 의미가 퇴색되는 방법은 아닐 것이다.

겉보기엔 편해 보인다. 팀원들은 조립해 둔 모달 컴포넌트를 보고 이해한 뒤 필요한 곳에 꺼내서 쓸 수 있을 것이다.

 

그러나 이렇게 하니 다시금 모달에 모달을 띄워야 하는 상황을 고민해야 하는 굴레에 빠질 수밖에 없었다.

 

모달에 모달을 띄우려면 상위 모달의 내용물인 diarySetting을 부모 컴포넌트 안에 풀어야 하고 거기에 또 하위 모달을 붙여야 한다.

결국 모든 것이 부모 컴포넌트 안에서 이뤄져야만 하는 것이다!

그렇게 할 거라면 컴포넌트를 쪼갠 의미가 퇴색된다고 생각됐다..

고찰의 순간

 

남들이 보면 뭐 이딴 걸로 고민하고 있냐 할지 모르겠지만, 나에겐 상당히 중요한 순간이었다.

팀원들도 쉽게 사용 가능하도록 만들고 싶었고, 클린한 코드를 짜고 싶었으며, 추상화와 편의성에 대한 고민까지 모든 것이 뒤얽혀 골머리를 앓게 만들고 있었다.

 

그래서 결국 내린 결론은...'해치웠나?' 때 썼던 그냥 필요할  때 부품들을 꺼내 쓰는 방식이 제일 나은 것 같다는 생각에 도달했다.

사실 필요할 때 모달을 가져다 써야 하는 것에는 어떤 방식을 쓰든 변함없었다.
규격화한다고 해서 모달을 한 번 덜 쓰거나 그렇게 되는 것은 아니니까.

 

'컴포넌트는 반드시 분리하고 쪼개야만 해'

'코드를 한 번이라도 덜 써야만 해'

나를 괴롭혔던 망령들...

 

근데 생각해 보면 결국 모든 것은 개발자들 편하자고 만들어진 것 아닌가.

 

컴포넌트를 쪼개고 컴포넌트화 하고 모두 좋지만, 성능이 비슷하다면 그것들이 편의성과 효율 위로 올라올 순 없을 것이다.