블로그 회고작성 :
- https://yess.tistory.com/12 (토글 리팩토링)
프로젝트 관련(구현간 어려웠던점)
- 직접 코드를 작성하기전에 구조파악,상태관리에대한 설계과정을 무시한점.
- 왼쪽 배너부분의 목록을 불러오는 재귀함수만 구현하면 나머지는 그렇게 어렵지않게 구현할 수 있을것이라는 판단했다. 하지만 막상 재귀함수를 구현한 이후에 추가적으로 기능(문서생성기능,문서 삭제 기능)을 구현해 나갈때 좁은 범위에서 생각을 해 나가다보니, 코드자체의 가독성도 떨어지게되고 이렇게구성을해도 될까라는 의심이 들게되었다. 그렇게 찝찝한상태에서 추가기능인 문서생성 버튼과,문서삭제버튼을 구현한 결과 이후 생성된 문서의 +버튼과 -버튼은 동작을 하지 않는 현상이 발생했다. 이는 추가적으로 생긴 돔에대해서는 이벤트가 할당되어있지않아서였고, 최초에 렌더링시 이벤트를 할당하는 로직 + 새로 생겨난 돔요소에 적용될 이벤트로직이 중복되어 작성되는걸보고서 뭔가 잘못된 길로 가고 있다라는 생각이 들었다. 아무리 작은프로젝트일지라도, 어려워보이지 않을지라도 막상 들여다보면 어려운 지점이 반드시존재하고, 어려운 지점이 없더라도 미리 구상을 하고 작업을 했을때와, 그렇지 않았을때의 코드를 작성하면서의 의심(?)이나 확신적인 부분에서 차이가 분명히 존재하는것같다.
- api명세에대해 제대로 이해하지 못한점.
- 위에서발생한 문제점에 포함되어있는데 상황은 이렇다. 문서생성버튼을눌러 새로운 문서를 만들었을때 이 문서를 삭제하기위해 삭제버튼을 누르면 화면에선 없어진다. 그런데 새로고침을 하게되면 삭제되지 않는 상태로 배너가 구성되어 어려움을 겪고있었는데 팀원분들의 도움을통해 알아낸결과 생성을위한 POST요청엔 ID값이 클라이언트에서 보낸값으로 설정되는것이 아닌, 서버에서 자체적으로 생성되는 방식으로 API가 설계되어있었다는것이다. 서버요청을 보내면서 넘겨줬던 ID값으로 새로운 돔을 그리다보니, 삭제요청을 보낼때의 ID값이 DB에 당연히 등록되어있지 않을테고, 삭제처리가 제대로 동작하지 않는게 당연한 상태였다. 이는 내가 POST요청에대한 응답값을 파악하지 못한상태로 화면을 구성한 잘못이였고, 이또한 전체적인 큰그림을 파악하지 못한상태(API명세를 정확하게 인지하지 못한상태)에서 작업을 진행함으로써 발생한 오류였다라고 생각된다.
- 삭제기능을 구현하는데있어서도 같은이유(api명세파악)로 시간을 상당히 많이 잡아먹은 상황이 발생했는데 상황은 이렇다. 자식 문서가 있는 문서를 삭제했을때 들었던 생각은 당연히 현재 삭제된 위치로 자식 문서들이 붙여질것이라고 생각하고 구현했다. 하지만 새로 get요청을통해 화면을 그릴때와 화면구성이 다르다는 점을 보고 명세서를 확인해보니 내가 생각했던 방식과 다른 방식으로 화면에 렌더링이 되는 것이였다. 따라서 서버요청을 하기전에 명세서를 충분히 이해한 상태에서 코드 작성을 진행해야하고, 실제로 그렇게 동작하는지도 확인해 볼 필요가 있다라는 생각을 하게되었다.
팀관련
- 좋았던 경험.
- 한 사람이 겪고 있는 문제에 대해서 팀원 전체가 적극적으로 고민을 해결해주려 노력했다.
- 오프라인에서 좀더 느낄 수 있었는데 확실히 이런 소통관련해선 아무리 화면을 보고있다한들 온라인보단 오프라인이 좀더 전달력이 좋다라는 생각이 들었다. 예시로 오프라인에서 코드작업을 하던중 도움을 요청한 팀원이 있을시엔 직접 그사람의 자리로 모여 함께 고민했던 순간이 좋은 팀분위기를 갖췄다라고 생각이 든다.
- 팀원들의 코드를 보고 실제 이론을 어떻게 적용하는지 참고가 되어 도움이되었다.(pub-sub구조,재귀함수,toggle상태)
- 아쉬웠던경험
- 어떤식으로 접근할것인가를 미리 설정하는 단계를 거쳤었다면 내가 진행하고 있지 않는 부분에서 다른팀원분들이 어려움을 겪고있을때 함께 생각해 줄 수 있었는데 미리 설정하는단계를 거치지않아 내가 경험하지 못한 고민에대해선 충분한 답변을 드리기가 어려웠다. 이게 팀프로젝트로 진행되었을시엔 결국엔 모든 팀원들이 자신의 파트뿐만이아니라 프로젝트의 전반적인 방향을 알고 있어야 서로에게 도움이 될 수 있을것같다라는 생각이 들었고, 큰그림에대한 이해의 중요성을 느낄 수 있었다.
개인 역량 & 성장관련
- 기존에 사용하던 리액트의 동작원리인 상태변경 → 렌더함수 호출→ 리렌더링발생 → UI구성에 대해서 어떻게 이런 동작이 이루어지는지 직접 코드로 확인해 볼 수 있었습니다.
- 단순히 리액트라는 도구(?)를 사용하고 있는 생각이 들었었는데, 직접 순수 자바스크립트로 구현해보니 자바스크립트 라이브러리로써 결국엔 자바스크립트로 동작하느구나! 라는 생각이 들었다.
- 코드 품질에대해서 고민해보는 경험.
- 컴포넌트간의 소통을 오직 custom이벤트를통해 구성함으로써 컴포넌트간의 의존성을 낮추고, 응집력을 높혀 이전보다 컴포넌트의 재사용성을 높힐 수 있는 방법을 배웠다.
- history API를통해 SPA에서의 화면전환이 이루어지는 원리.
- history.pushState로 브라우저의 url를 변경시키면, route함수에서 url을 읽어오고 여러 조건문을 거쳐 해당 url에 보여줄 컴포넌트의 렌더링 함수를 직접 호출 해야하는 과정을 경험해 봄으로써, 이전에 사용하던 리액트의 react-router-dom 라이브러리의 편의성에대해서 느낌.(history.push(url) → url에 해당하는 컴포넌트 호출)
- 동적으로 업데이트되는 부분에서 상태기반 렌더링의 필요성.
- 왼쪽 배너에서 문서를 추가,삭제등의 동적으로 업데이트하는 상황에서 상태를 기반으로 업데이트를하지않고 직접 돔에 접근하여 업데이트를 진행할 경우 이후 사용자 경험을 유지시키기위해서 가독성이 떨어지는 코드를 작성함과동시에 예상하지 못할 에러가 발생하기 쉽다라는 생각이 들어 상태변경 → 렌더링 방식을 왜 리액트에서 사용하는지에대해서 조금이나마 공감할 수 있었다.