본문 바로가기

개발/개발일지

 (7)
협업 잘하는 개발자로 거듭나기 위한 발자취 들어가며 사실 소프트 스킬에 강점을 가지고 있다는 생각을 했기 때문에 '협업? 별로 어렵지 않지'라고 생각했고, 협업에 대한 거부감은 없었던 것 같다. 학교생활 중 과 학생회의 홍보부원으로 시작하여 홍보부장을 거쳐 부회장, 회장을 경험했기에 여러사람들과 일하는 것에 대해 문제는 없을 것이라는 막연한 생각....하지만 오산이었다. 생각보다 어렵고 생각보다 막히는 부분들이 많았다. 이 글에서 모든 걸 담을 순 없겠지만, 협업을 위해 고민했던 내용 시도들을 정리하며, 이후 프로젝트나 회사에서 같이 일하고 싶은 개발자가 되기 위해 돌아보려한다. 학교생활 학교생활에서도 개발프로젝트는 아니지만, 회장을 맡게되면서 3개월정도의 학술제라는 프로젝트를 주도했던 경험이 있다. - 주단위 스프린트 학술제를 위한 주차별 테스..
"Skeleton UI" 와 "사용자 경험 개선"의 은밀한 관계 들어가며 머리를 맞았다! 시작은 "실서비스가 아닌걸 어떻게 유저데이터를 모아요? 다른 방법 없어요?" 라는 종택님의 질문에 나는 "아..맞네..?" 라는 대답을 하고선, 고속도로가 뚫리는 기분이 들었다. 데이터는 '유저데이터만 있는게 아니었지!' 에서 이 글은 시작된다. 선생님들,,, 유저경험 개선 된다면서요? 프로젝트의 홈 화면에서는 게시물 목록 API를 사용하여 화면을 구성한다. 특별한 비즈니스 로직이 포함되어 있지 않기에, 사용자 환경이 양호하다면 API 응답 지연시간이 거의 존재하지 않는다. 네트워크탭에서 설정할 수 있는 네트워크 설정에 따른 화면의 연출을 보여준다. 네트워크 제한 없을 때 화면 [제한 없음 모드] skeleton 처럼 보이는 로딩 UI 가 잠시 화면에 나타났다 사라지면서 깜빡임을..
왜 queryClient 설정에 useState를 사용할까? 기존에 진행한 프로젝트들에서는 react-query의 쿼리와 쿼리 상태를 관리하는 메소드들을 포함한 객체인 queryClient를 설정해서 option 등을 정의하기 위해서 queryClient를 컴포넌트 외부에서 선언하고 사용했다. 이는 라이프 사이클에서 한 번만 초기화되어 사용됨으로써 참조 동일성을 유지하게 된다. const queryClient = new QueryClient({ defaultOptions: { queries: { retry: 1, refetchOnWindowFocus: false, useErrorBoundary: true, }, }, }); ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render( ) n..
지역 중고거래 및 정보교류 커뮤니티 프로젝트 마이그레이션 후기(1차) 원티드의 프론트엔드 코스를 마무리하고나서, 협업에는 익숙해졌기에 내가 혼자서 코드를 구현하고 구조를 고민하고 만드는 것에 대한 갈증을 느꼈다. 동시에 협업을 하면서 사용했던 vite의 성능 측정을 하고 싶었고, 잘 모르던 상태에서 했던 기존 코드를 개선해보는 경험이 있다면 기존 서비스를 유지 개선하는 역할을 맡게 되더라도 더 자신있게 맡을 수 있을 것 같았다. 그래서 당근마켓 디자인을 기반으로 클론했던 지역 중고거래 및 정보교류 커뮤니티 프로젝트를 개선해보고자 했다. github repo link: https://github.com/jong6598/daangn_FE_refactoring GitHub - jong6598/daangn_FE_refactoring: 지역 중고거래 및 정보교류 커뮤니티 프로젝트 ..
ErrorBoundary 심층 적용기 기존의 에러바운더리 적용 방식은 Global ErrorBoundary 라고 명명할 수 있을 것처럼 전체를 감싸는 에러바운더리를 작성해서, 잘못된 페이지를 접속했거나, 요청이 잘못되었을 때 등 발생하는 에러를 모두 한꺼번에 처리해서 상황에 따른 핸들링을 하지 않는 방식으로 사용했습니다. 이렇게 사용한 에러바운더리는 다음과 같은 유저의 불편함을 만들었습니다. 1. 일부 컴포넌트에서 api 요청을 해서 데이터를 비동기로 가져올때, 여러가지 에러상황이 나올 수 있는데, api 재요청을 통해서 다시 정상적인 UI를 보여줄 수 있는 상황에서도, 공통 로직으로 작성된 errorBoundary로 연결되는 상황이 발생합니다. 이후 설정된 로직에 따라 다르겠지만, 유저는 정상적 UI를 보기위해 다시 에러가 났던 페이지로 ..
Optimistic UI(낙관적 UI) Optimistic UI(이하 옵티미스틱 UI) 에 대해 알아보자! 기존의 버튼 인터랙션 1. 사용자가 버튼을 클릭 2. 버튼이 비활성화 상태로 바뀜 3. 서버에 신호가 전달되고 4. 서버에서 다시 페이지로 응답을 보낸다 5. 응답 결과를 보여주는 페이지가 새로 로딩된다. 이러한 기존의 버튼 인터랙션은 예측이 가능하고 오류가 나타날 가능성이 적다. 로딩상태일때 비활성화 상태의 버튼이 서버에 신호가 간 것을 확인시켜주고, 서버가 응답을 주면 페이지가 업데이트 되면서 인터렉션이 끝났음을 알려주는 직관성을 가진다. 하지만 이러한 기존의 방식은 다음과 같은 문제들을 가진다. 사용자의 인내심을 필요로 한다. 서버 최소 응답시간이 길어질 수록 페이지와 브랜드 이미지에 부정적인 영향을 줄 수 있다. 기존의 페이지가 ..
[Trouble Shooting] useMutation을 활용한 생성, 수정, 삭제 서버 데이터를 관리하기 위한 React Query의 사용 React-Query는 데이터를 fetching 해온 후, 데이터를 캐싱하게 되고, stale 상태의 데이터를 refetching 하게 된다. 브라우저에서 사용자들은 화면을 바라보고 있을 때, 페이지가 전환될 때, (클릭과 같이) 데이터를 요청할 때 최신의 데이터를 받아봐야한다. React-Query의 경우 WindowFocus, Mount, Reconnect, stale data 의 상황에서 refetch를 실행함으로써, 데이터의 fresh 한 상태를 유지한다. 유저정보를 전역상태관리함. => 유저정보에 전역상태관리툴을 사용한 이유는, React-Query는 서버 데이터 관리에 특화되어 있기 때문이다. (서버를 거치느냐, 브라우저에만 국한되는 사..

티스토리툴바