월간 키워드 - 2021년 10월

 

 

💻 웹 접근성

Week 1

iOS ux 피드백을 받았다. 인풋창에 포커스가 갈 때 예상치 못하게 zoom-in이 된다. 폰트 사이즈가 16px보다 작으면 iOS에서 잘보이라고 알아서 확대해주는 것이다.

이 이슈를 해결하는 방법으로는 meta 태그를 수정해주는 작성하는 방법이 있다. 

<!-- 변경 전 -->
<meta name="viewport" content="width=device-width,initial-scale=1"/>

<!-- 변경 후 -->
<meta
    name="viewport"
    content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"
/>

그런데 이 방법은 일반적인 UX가 향상될지는 몰라도, 웹 접근성은 오히려 해치는게 아닐까? 하는 생각이 들었다. 이 이슈와 해결방법에서 디자인, UX, 접근성 세 가지 가치가 충돌(?)한다. 

[디자인] 앱의 디자인 통일성을 생각하면 16px 이상으로 키울 수 없다.
[UX] 앱의 UX를 생각하면 갑자기 확대되면 당황스럽다.
[접근성] 앱의 웹 접근성을 생각하면 16px 이상이 아니거나 확대안하면 보기힘들다. 애플에서 고심해서 '이것보다 작으면 확대해서 보여줘야해.' 라고 정한걸 감히 우리가 덮어씌워도 되는지 의문이다.

디자인, UX, 접근성 셋 모두를 동시에 챙길 수 있는 방법은 무엇일까? 

UI/UX로 유명한 사례에서도 폰트 크기가 16px보다 작은 경우를 찾아볼 수 있다. 무조건 글씨 크기를 16px로 키우기보다는, 기존 디자인을 유지하면서 사용자가 본인에게 편한 폰트사이즈 등을 커스텀할 수 있는 기능을 제공하는게 베스트 솔루션이겠다. 이 솔루션은 앱의 규모가 어느정도 있을 때 적용하면 좋을 것 같다.

우리 프로젝트에는 meta 태그 수정을 적용하는게 당장은 최선의 선택이 아닐까..

 

Week 2

모바일 웹접근성 점수 확인하려고 라이트하우스 돌린건데 웹접근성도 그렇지만 성능 점수가 심각하다.

모바일에서 사용하지 않는 지도 로직을 가져오고 있는데 그것부터 개선해보아야겠다. display: none 이라 렌더링만 안할 뿐 지도를 그리는데 필요한 리소스를 다 받아와서 확실히 비효율적이다.

라이트하우스 성능 점수

 

💻 상태관리

Week 1

게시판 기능을 추가하면서, 간단할거라 생각하고 상태 설계를 안하고 기능을 구현하고 있다. 그런데 그러다보니 데이터를 자식 컴포넌트로 옮겼다가 다시 부모 컴포넌트로 옮겼다가 하는 식으로 계속 코드를 수정하게 되었다.

게시판 목록 데이터와 연관된 건 오직 <ArticleList> 에서만 필요할 거라 생각하고, 가장 처음에는 <ArticleList> 컴포넌트에서 totalList를 가져오는 useBoard 훅을 실행했었다.

그런데 뒤로가기로 게시판 목록으로 돌아가는 경우에, 과거에 이미 요청을 통해 받아온 게시글 목록을 그대로 다시 띄워주기 위해서는 unmount 된 후에도 totalList 상태를 유지시켜줘야 했다. 따라서 <ArticleList>의 부모 컴포넌트 <BoardPage>에서 useBoard 훅을 호출하는 것으로 변경했다. 

그래서 현재는 상태 끌어올리기가 되어있는 상황인데 props로 다 내려주려니까 prop drilling depth가 깊은 것도 아닌데 코드가 별로 깔끔해 보이지 않는다. 그렇다고 Context API를 쓸 일은 아닌 것 같다. 딱 하나의 컴포넌트만 그것도 딱 한 레벨 아래에 있는 컴포넌트에서만 쓸 거기 때문이다. 더 좋은 방법이 있을지 고민된다.

Week 2

게시글 삭제 기능을 붙이는데, 게시글 totalList를 사용하는 복잡도가 너무 커져서 결국 Context API로 관리하기로 결정했다. Context API를 쓰게될 거라고 전혀 예상하지 못했다.

구상한 기능은 <ArticleView> 에서 사용자가 '삭제 버튼'을 클릭하면 정말 삭제할지 확인하는 '컨펌 창'이 뜨고 '확인'을 누르면 서버로 요청을 보내는 것이었다. 이 때, 정상적으로 게시글을 삭제 되었다면 게시글 전체 목록에 해당 글이 남아있으면 안된다는 것, 즉 totalList도 업데이트 되어야 한다는 것을 구현하면서 깨달았다.

우리 프로젝트에서 사용하는 useConfirm 훅은 호출할 때, approve일 때 동작시킬 함수를 인자로 받아서 사용한다. 따라서, <ArticleView> 컴포넌트에서도 게시글 목록을 동기화시켜주는 setTotalList 함수가 필요했다.

이를 구현하기 위해서 <BoardPage>에서 useBoard 훅을 호출해서 가져온 setTotalList 함수를 <ArticleView> 에 props로 넣어준 다음, 이를 다시 useConfirm의 인자로 넣어주는 기이한 형태가 되었다.

훅으로 가져온 함수를 자식 컴포넌트에게 props로 넘겨주고, 그걸 다시 자식 컴포넌트가 사용하는 훅의 인자로 넣어주어야 하는 상황...

이런 상황이 되기 전까지 왜 context로 구성할 생각을 못했을까? 상태 설계를 했다면 미리 파악할 수 있는 문제였을까?

페어와 나는 '미리 고민했어도 구현하고 나서야 깨달았을 것 같다'는데에 동의한다. 이제와서 생각하면 당연하지만 <ArticleView> 컴포넌트에서 setTotalList 함수로 목록을 동기화해주어야 한다고 전혀 예상하지 못했기 때문이다. 페어의 표현을 빌리면 '아직 주니어이기 때문에 겪는 시행착오' 인 것 같다. 

Context API로 바꾸고 나니 코드 복잡도가 많이 해결되었다. 과정이 너무 아쉬운 구현이었다. 그래도 다시하면 더 잘할 수 있겠지.