Antd와 Mantine 잡담

Antd를 먼저 도입해서 쓰고 있었는데, 기능은 많지만 빌드 용량이 너무 무거워서 Mantine으로 점진적으로 교체중이다.

vscode의 cost impact라는 확장프로그램만 봐도 antd는 mantine의 2~3배는 찍는달까

다만, mantine은 도입초기, 서양에서 만든거 답게 padding이 넉넉한 편이라 전체를 뜯어고치고픈 욕구가 치미는데, 사이트의 문서가 너무 부실하여 provider에서 적용가능한 설정을 고치고 또 고치고 난리도 아니었다. 
styles나 vars등으로 고칠 수 있는 부분이 꽤 많지만, css로만 가능한 영역도 혼재해 있어서 시행착오가 제법 컸달까. 쓰다보니 설계가 좋은 편이라 커스텀해서 쓰기 잘 되어 있는건 맞는데, 아쉬운 부분도 있어서 요즘은 해당 프로젝트를 git으로 받아서 코드를 보면서, 컴포넌트를 고쳐 쓰는 경우가 잦아지고 있다.

예를 들면, datepickerinput, monthpickerinput, yearpickerinput이 따로 있다.
모를때는 따로 따로 import해서 썼지만, 코드를 살펴보니 datepickerinput에서 minLevel이라는 속성만 쓸 수 있다면, 하나로 퉁칠 수 있는 구조였다. 실제로 써보면 타입에러는 나지만 동작은 한다.ㅋㅋㅋ
이렇게 간단한 것도 있지만, 생각보다 거대한 경우도 있는데, datepickerinput을 보면 좌우에 이전달, 다음달 이동 버튼은 있지만, 전년, 후년 이동 버튼은 없다. 이걸 넣고 싶은데 header에 버튼을 넣는 방법이 없다. 코드를 보면 이게 calendar 컴포넌트를 재사용하는데 여기에 그 기능이 없기 때문이다. 고로 그 header에 그 버튼을 넣고 싶다면, calendar 컴포넌트부터 고쳐야 하고, 그 고친것을 datepicker에 넣어줄 수 없기 때문에 또 datepicker 컴포넌트를 고쳐야 하며, datepickerinput 컴포넌트에서 그걸 PickerInputBase 컴포넌트로 감싸야 최종 사용이 가능하다.

또다른 케이스로는 quarterpickerinput이 필요했다. 그래서 calendar, monthpicker, monthpickerinput, monthlist, yearlevel, yearlevelgroup 컴포넌트 코드를 받아서 month를 quarter로 고쳤.....

딴길로 샜는데 아무튼, 결과적으로보니 커스텀해서 쓰기좋게 잘되어있긴 한데, 써보니 styles나, vars로만 하는 건 한계가 있어서 css로 병행해야 하는 부분도 있는데, 앞에도 적었지만, 사이트의 문서가 많이 부실하여 그로 인한 러닝커브가 다소 높은 편이랄까. 특히 vars가 이게 타입으로 잘 뜨는 것도 있지만, 어떤건 없지만 되는 것도 있고ㅋㅋㅋㅋ 그냥 개발자도구로 보면서 고치는게 된달까...
이렇게 보면 고생스러워 보이긴 결과적으로 페이지에서 antd 컴포넌트 하나둘 덜어낼때마다 빌드후 페이지 용량이 nnKb씩 줄어드는거보면 뿌듯하긴 하다. 

그리고 mantine이 요즘 열일하는 느낌이라 응원하게 된다. v9부터는 select와 multiselect의 value를 숫자도 쓸 수 있게 해주고, tree select도 생겼고(아직 value는 문자열밖에 안되지만),  splitter도 추가되기도 했고 (다만, toggle 기능을 내장안해놓는 바람에 SplitButtonGroup, Splitter.context, Splitter, SplitterPane 코드 받아서 수정한건 함정)
schedule 패키지도 9.3까지 테스트 했을때는 버그가 있어서 쓰지 못했지만, 9.4에는 그토록 원했던 resource view들도 생겼다.

그 사이 antd는 요즘 버전만 올라가지 새 기능은 별로 없어서 한동안 살펴보지 않다가, 최근에 확인해보니 Masonry라는 높이가 다른 벽돌식 레이아웃 요소라던지,  BorderBeam이라는 아주 깜찍한(?) 컴포넌트가 생기긴 했다.

antd가 무거워서 그렇지 기능이 좋긴 좋은데, 묶어놓은 컴포넌트들을 안에꺼만 쪼개서도 불러올 수 있게 해줬다면 이런 수고는 안 했을려나?
antd의 form과 cacader는 현재로선 대체 불가라 antd provider를 걷어내는 날이 올까 싶다.