일단 해보는 기록

이전 좋은 UX를 위한 보이지 않는 에러 다루기 글을 통해 예외 처리에 대해 알아보았다.이번에는 프로젝트를 진행하면서 겪은 관련 트러블 슈팅을 정리해 본다. *참고: 스크럼블은 JSESSION 기반 인증 방식과 리액트 쿼리를 이용해 서버 상태를 관리한다.Case 01. 잡히지 않는 에러에러가 눈에 보이는데 잡히지 않는다. 이게 무슨 말인가 싶을 수도 있는데 말 그대로 에러가 발생할 것이라 예상되고, 발생해야 맞는데 에러바운더리로 전달이 되지 않는다. 문제 상황로그인 후 스쿼드 목록을 조회하면, 서버에서 세션의 유효 여부를 검사한다. 이때, 브라우저 쿠키에서 세션 정보를 임의로 삭제한 뒤 뒤로 가기 후 다시 스쿼드 목록을 조회하면, 캐시 데이터가 `stale` 하면 리페치가 실행되어 `ErrorBounda..

FrontEnd 2024. 12. 22. 17:54

들어가며 스크럼블 프로젝트에서 백엔드 개발자와 처음 협업을 경험했다. 이전에도 에러 핸들링에 대한 갈망이 있었지만, 사용자가 없어 이에 대해 우선순위를 두지 못했다. 하지만 서비스를 개발하고, 운영하며 사용자가 직접 사용하게 된다면 기능이 동작하는 것은 기본이고, 발생할 수 있는 에러에 대비해 사용자의 이탈을 막아야 한다. 많이들 하는 얘기로 로딩 시간이 3초가 넘어갈 때부터 이탈률이 높아진다고 하는데 이 확률을 뚫고 기다려줬는데 에러가 발생해서 다음으로 진행하지 못한다면? 끔찍하다. 마침 스크럼블은 직접 사용하려고 만들게 된 만큼 에러 핸들링에 대해 더 고민해 볼 수 있는 기회가 되었다. 이전에는 에러 발생 지점을 예측하고 피해 다니며 테스트를 했다면, 이번에는 어떻게든 에러를 만나고 싶어서 안달 난 ..

FrontEnd 2024. 12. 16. 12:53

들어가며취미로 개발을 배울 때, 상태라는 개념과 활용도 알까 말까 하며 Redux(툴킷 X)도 겨우 이해하고 있는데 서버 상태라는 개념에 좌절했던 기억이 난다. 완전히 개발자로의 전향을 결심한 뒤에 시작한 모든 프로젝트에는 React Query를 사용했다. 처음에는 데이터 페칭 상태 관리가 너무 편해서 사용했고, 최근 스크럼블 프로젝트에서는 백엔드와 협업하면서 네트워크 호출을 줄이기 위한 고민을 많이 하게 되면서 알차게 활용할 수 있었다. * TanStack Query로 명칭이 변경되었지만, 해당 글에서는 React Query로 사용했다. React Query, 꼭 써야 할까?리액트 쿼리를 프로젝트에 도입하는 주요 목적은 데이터 페칭에 대한 상태 관리와 캐싱으로 생각해볼 수 있다. 서버와의 통신은 언제나..

FrontEnd 2024. 12. 8. 21:41

CORS란?[Cross-Origin Resource Sharing]웹 브라우저가 서버와 다른 도메인에서 리소스를 요청할 때 적용되는 보안 정책이다. 동일 출처 정책이라고 하는데 간단히 말하면 같은 도메인끼리 데이터를 주고받아야 안전하다는 것이다.// HTTP 헤더를 사용하여 허용할 도메인을 추가할 수 있다.Access-Control-Allow-Origin: 도메인CORS 에러라는 단어 자체를 고유 명사처럼 너무 많이 들어서 직접 경험해보고 싶었는데 이번 프로젝트를 진행하면서 원없이 경험할 수 있었다. 클라이언트 vs 서버, 누가 해결할래?프록시를 사용하여 클라이언트에서 CORS 문제를 해결하는 것은 완전한 해결이 아니라 단지 우회일 뿐이다. 서버가 적절히 CORS 설정을 하지 않으면, 클라이언트는 자유롭..

FrontEnd 2024. 12. 2. 23:08

프리코스는 11월 11일에 종료되었지만 4주 차 회고가 늦었다. 부담 갖지 말자고 되새겼지만 나도 모르는 새에 한 달 동안 너무 집중을 많이 했던 것 같다. 겨우 정신 차리고 너무 어렵게 느껴졌던 4주 차 미션을 다시 구현해 보았다. 이번 글은 미션 과정에서 마주쳤던 벽 위주로 작성해보려고 한다.파일 입/출력public 폴더의 md 파일을 보고 멈칫했다. 첫 번째로 보통 public에서 mock 데이터를 사용할 때는 json 형식이 많았었고, 두 번째로 불러올 때는 fetch를 이용해서 절대경로를 사용했었는데 둘 다 해당되지 않는 케이스였기 때문이다.  이번 경우에는 Node.js의 파일 입/출력 방법을 사용해야 했다. `fs`와 `path`를 활용하면 되는데 처음 해보는 것이라 조금 복잡하게 돌아 제출..

우아한테크코스 2024. 11. 19. 22:22

4주 동안의 프리코스 대장정이 끝났다. 원래라면 4주 차를 진행하는 동안에 3주 차 회고를 작성했어야 하지만 4주 차의 벽에 부딪혀 정신없이 구현하느라 3주 차 회고는 꿈에도 꾸지 못했다. 순서가 밀렸지만 천천히 3주 차부터 다시 돌아보는 글을 작성해 본다.변화기능 단위 커밋2주 차 공통 피드백을 받고 아차 싶었다. 기능 목록을 작성하는 방법에 대한 내용이 있었는데 내가 미션에 접근하는 방식을 다르게 해야 한다는 생각을 하게 됐다.기능 목록을 재검토한다기능 목록을 작성할 때 클래스 설계와 구현, 메서드 설계와 구현 같은 상세한 내용은 포함하지 않는다. 클래스 이름이나 메서드 시그니처, 반환값 등은 언제든지 변경될 수 있기 때문이다. 구현해야 할 기능 목록을 중심으로 작성하되, 정상적인 경우뿐만 아니라 예..

우아한테크코스 2024. 11. 13. 21:18

2주 차를 마무리하고 3주 차 로또 과제를 진행하며, 지난주 회고를 작성해 본다. 1주 차 과제에서는 구현 자체보다 다양한 예외 케이스를 처리하는 것이 어려웠던 것 같다. 반면, 2주 차 과제인 자동차 경주에서는 예외 처리보다는 책임 분리를 어떻게 더 잘할 수 있을지에 대한 고민을 많이 하게 되었다. 그리고 1주 차에 리팩토링 했던 방법을 기억하며 2주 차에 적용하는 과정이 자연스럽게 이어지면서, 조금 더 수월하게 구현할 수 있었다. 이번 주차에는 소감문에 중간 회고로 3가지 항목을 작성하도록 안내받았다. 지원서에 작성한 목표를 얼마나 달성하고 있다고 생각하나요? 그 이유는 무엇인가요?지원서에 작성한 목표를 변경해야 한다고 생각하시나요? 그렇다면 그 이유와 어떤 목표로 변경하고 싶으신가요?프리코스를 진행..

우아한테크코스 2024. 10. 30. 23:07

우테코 7기에 참가했다. 작년 6기 모집 공고도 보았었고, 주변에서 프리코스만으로도 많은 것을 배울 수 있다는 얘기를 들었지만 그때는 독학을 하며 적응하던 차라 프리코스마저 무섭다는 생각이 들어서 회피했던 기억이 난다. 이번에는 그때보다는 괜찮지 않을까라는 생각과 같은 기능을 다른 사람들은 어떻게 구현하는지 보면서 다양한 관점을 경험해보고 싶어서 주저 없이 신청했다. 그렇게 지원은 가벼운 마음으로 했지만, 막상 과제가 나오는 당일이 다가오자 정말 긴장을 많이 했다. 회고를 쓰는 지금에 생각해 보면 긴장했던 이유는 나름 1년 동안 공부를 꾸준히 해왔다고 생각하는데 과제를 받고 눈앞이 캄캄해지면 그동안의 노력이 물거품이 된 것처럼 느껴질까 무서웠던 것 같다. 지금은 무사히 1주 차를 마치고 차분히 되돌아 본..

우아한테크코스 2024. 10. 24. 03:33