바로 위의 링크를 읽고 정리했던 이유는 일단 이 글을 읽으면서 생각을 좀더 확실히 하기 위해서였다. 이전에 포스팅으로 ‘에러 처리를 어떻게 하면 좋을까’ 하고 고민을 해본 흔적은 있으나 명확한 결론은 내지 못한 채 코드의 유지보수성은 나락으로 떨어져갔다.
결국 중간 과정으로 어중간하게 Either(Result) 모나드를 활용하는 듯한 코드가 나오자, 이럴거면 이런 방식으로 에러를 처리하기 위한 당위성을 명확히 정리하여 팀 내부에 공유하고 필요한 도구를 도입하여 에러 처리 방식을 개선하자는 생각을 냈다.
이 글의 핵심은 ‘기대할 수 있는 에러(Expected Error)’ 는 던지지 말고 다른 방식으로 처리하자는 것이다. 위의 에러 처리 모범 사례 글에서 커스텀 에러가 언급되긴 했지만, 이런저런 문제가 있다는 것이다. 특히 “에러를 뱉을 수 있는 함수가 정확히 무엇을 뱉는가?” 를 특정하기 어렵다. throw 문으로 던져지는 에러는 리턴 타입이 아니고, 타입스크립트 타입으로 정의할 수 없기 때문이다.
그래서 value, error 가 있는 Result 타입 이야기를 꺼낸 것이고, 이 글에서는 실제로는 써먹기 어려운 아주 낮은 수준의 예제를 제공하고 있지만 충분히 타입스크립트로 명시적인 에러 처리를 위한 아이디어는 얻을 수 있었다.
덕분에 neverthrow 라는 라이브러리를 알게 되어 활용할 수 있게 되었다. 3년 전에 썼었던 Either 모나드 구현체에 비하면 아주 높은 수준으로 발전되어 있고 문서화도 잘 되어있어서 적극적으로 수용해보려 한다.
업무에서 모바일 대응을 할 일은 거의 없지만, 모바일로 접속한 사용자를 위해 프로토타입 재생을 위한 전용 페이지가 있다. 그런데 이전부터 iOS 사파리로 접속했을 때 앱으로 여는 것을 유도하는 버튼의 위치가 하단 툴바에 가려지는 문제 때문에 궁여지책으로 document.documentElement.clientHeight 을 처음 페이지 로딩 시 고정값으로 쓰고 있었다. 이렇게 하면 사용자가 직접 툴바를 없애는 동작을 실행할 시 레이아웃이 또 깨지기 때문에 제대로 된 해결책을 적용하지 못한 셈이었다.
그렇게 돌아만 가는 식으로 오랫동안 방치하던 페이지를, 이번에 landscape 지원을 하면서 다시 이런저런 수정을 가할 일이 생겼다. 구현은 팀 동료분이 하고 계시긴 하지만, 관련된 레이아웃을 잡는데 도움이 되도록 같이 조사를 조금 하다보니 괜찮은 글을 발견했다. window.innerHeight 을 잡아내서 임의의 CSS 변수로 할당하고, 그 변수가 100vh 보다 약간 낮지만 연관된 수치가 되도록 조정을 하는 것이다. 그리고 calc 함수를 이용하여 계산하도록 하는 것이다.
아마 회사에서 모바일 애플리케이션에 들어가는 웹뷰를 작업하시는 분들이나 모바일 웹사이트 대응을 많이 해야 하는 분들은 이미 경험을 통해 충분히 숙지하고 있을만한 해결책이라고 생각된다.
연관된 글로 이 글도 매우 유용한데 사파리 웹킷에만 적용되는 속성인 -webkit-fill-available 을 이용하여 사파리의 툴바 문제는 그럭저럭 해결할 수 있다 하더라도 다른 브라우저의 레이아웃에 맞추는 것은 어차피 윗글의 설명대로 해야 될 것이다.
특정 페이지에 접속할 때 비밀번호를 입력하여 들어간 다음, 패스워드 입력에 성공한 컨텐츠를 다운로드 받을 때 아무런 보안 제약이 없는 <a href> 태그를 클릭만 하는 것이 아니라 fetch 를 통해 GET 요청을 서버와 주고받는 식으로 파일을 다운로드 받는 기능을 구현해야 했다.
언제나 대체로 유용한 정보를 제공하는 LogRocket 블로그 답게 내가 필요한 정보 뿐 아니라 ‘브라우저에서 파일을 받는 방법’ 이라는 것을 A부터 Z까지 잘 짚어서 알려준다. 저기서 나는 응답을 blob 객체로 만든 다음 URL.createObjectURL 함수에 넘기는 방식을 활용했다.