서론
일주일이나 글을 쓰지 못해서 많이 아쉽다.
컨디션 조절을 하지 못한 내 탓이지만 항상 아쉽고 야속하기만 하다.
머리는 더 할 수 있다고 하는데 몸은 그거 아니라도 하고
이전에 정보업무를 할 때 조근무를 할 때와 비슷한 증상이다.
당시에는 강제로 잠을 못자는 환경이었다면
지금은 자발적으로 잠을 줄여가며 코딩을 한다는 차이가 있을 수 있겠다.
어제는 아예 쓰러지기 직전까지 갔으니까 그때보다 조금 더 심하게 채찍질 했을지도 모르겠다.
이번주는 리액트를 시작하고 나서 첫 협업이었다.
json-server 를 이용해서 mock data 를 만들어 서버가 있다고 가정하고
AJAX 요청을 통해 데이터를 주고받는 첫 실습이기도 했다.
이번주에 배정된 팀원들은 반 내에서 잘한다고 소문이 자자하신 분들이었고,
배워갈 내용이 많을거라고 기대가 많이 되었던 것 같다.
돌이켜 생각해봐도 틀린 기대는 전혀 아니었고.
오히려 기대했던 것 보다 훨씬 많이 배웠고 훨씬 많이 성장했던 한 주였다.
본론
코드
구상했던 와이어 프레임
1. 메인 페이지
모달을 띄워서 게시글을 추가할 수 있다.
유효성 검사는 조금 어설프게 구현이 된 것 같다.
개인적으로는 라벨별로 색을 다르게 하고 라벨 선택시에 상호작용을 추가했으면
더 좋았을 것 같다.
이 부분은 내가 구현한 부분이 아니라서 크게 피드백 할 것은 없어 보인다.
2. 메인 페이지 검색기능
검색창에 키워드로 검색을 할 수 있고
밑에 라벨을 누르면 라벨로 라벨을 포함하는 키워드를 검색할 수 있는 기능.
팀에서 가장 실력이 뛰어나신 분이 구현을 맡았으므로 (추가기능으로 집어넣었다)
음음 역시~ 하면서 감탄했던 것 같다.
어떻게 이렇게 구현을 하나 감탄이 나올 따름이다.
코드는 너무 훌륭한데 조금 개선했으면 좋겠다고 생각하는 부분은
<Box
flexWrap="wrap"
gap="40px"
display={searchTodo !== null ? "flex" : "none"}
>
{searchTodo?.length > 0 ? (
searchTodo?.map((el, i) => {
return <BoxCard key={`box${i}`} el={el} />;
})
) : (
<p>검색결과가 없습니다.</p>
)}
</Box>
<Box
display={searchLabel !== null ? "flex" : "none"}
flexWrap="wrap"
gap="40px"
>
{searchLabel?.length > 0 ? (
searchLabel?.map((el, i) => {
return <BoxCard key={`box${i}`} el={el} />;
})
) : (
<p>검색결과가 없습니다.</p>
)}
</Box>
<Box
display={
searchLabel === null && searchTodo === null ? "flex" : "none"
}
flexWrap="wrap"
gap="40px"
>
{todolist?.length > 0 ? (
todolist?.map((el, i) => {
return <BoxCard key={`box${i}`} el={el} />;
})
) : (
<p>등록된 콘텐츠가 없습니다.</p>
)}
</Box>검색 결과를 바꿔주는 방식이 조금 아쉽다고 생각했다.
코드의 중복을 막을 수 있는 방법은 없었을까 ?
단순한 생각에는 display 부분의 반복문을 조금 중첩해서 사용했으면 됐을지도 모르겠다.
이 부분 역시 내 파트가 아니었으므로 크게 피드백을 할 수는 없을 것 같다.
3. 상세 페이지
포스트의 디테일 버튼을 누르면 디테일 페이지로 넘어가게 된다.
디테일 페이지에 포스트 RUD, 댓글 CURD 기능을 추가했다.
수정 버튼을 누르면 span -> textarea 로 바뀔 수 있도록 하려면
생각보다 고려해야 할 내용이 많았다.
내가 구현을 맡은 댓글 파트의 경우
버튼을 누른 댓글만 수정하고 싶으므로 이벤트가 일어난 대상의 id를 추적해야 했고,
수정한 댓글의 내용이 정상적으로 반영될 수 있도록 수정 이후의 value를 저장할
state를 추가로 만들어주는 꽤나 복잡한 작업이 필요했다.
그리고 댓글기능을 추가할 당시 redux-thunk 의 용도를 제대로 알지 못해서
제대로 구현을 하지못한것도 많이 아쉽다.
toolkit reducer에 무작정 axios로 json-server에 ajax 요청을 보내고,
요청과 별개로 initialState를 수정하는 로직을 짰다.
해당 내용을 컨펌 받았을 때
'이 로직이 과연 올바른 로직일까요 ?' 하는 말을 들어야만 했다.
이유인 즉슨 예를들어,
'서버에 POST 요청이 실패한다면요 ?' 같은 것이다.
서버에 POST 요청이 실패하더라도 reducer에서는 이미 state를 변경하는 로직을
수행했으므로 사용자의 화면은 바뀐다. 새로고침을 하면 그대로겠지만.
새로고침을 하면 그대로라는게 문제다.
내가 지금 보고있는 데이터가 정확한 데이터가 아닐 수 있다는 가능성이 있다는게
가장 큰 문제.
redux의 reducer는 '순수한 함수' 여야만 한다.
순수한 함수라는 의미는
어떤 특정 조건이나 분기, 확률에 따른 내용 변동이 없어야만 한다
라는 의미이다.
콩 심은데 반드시 콩이 나야하고, 팥 심은데 반드시 팥이 나야만 하는 것이다.
따라서 reducer에는 서버의 상태에따라 값이 달라질 수 있는 ajax 요청을 처리해서는 안된다.
redux를 처음 배울 때 이게 도대체 무슨 내용인가 했던게 이제서야 이해가 됐다.
결국 서버에서 요청을 받을때는 thunk 의 로직을 빌리는게 좋다는 뜻.
마지막 즈음에서야 thunk의 로직을 제대로 이해했고,
디자인 작업때문에 시간이 없어 로직을 수정하지 못한 부분이 가장 아쉽다고 볼 수 있겠다.
이 부분은 꼭 나중에 시간을 들여서 수정을 해보려고 한다.
결론
와이어 프레임과 전체적인 디자인을 맡아서 했다.
다들 디자인 팀장이라면서 전체 CSS 작업을 맡겨주는 부분이 고맙고 좋았다.
사실 개인적인 취향이 많이 들어가는 부분이지만
팀 단위 작업이다 보니까 내 멋대로 만들 수 있는 부분이 아니다.
그렇게 맡겨줬는데도 시간이 부족하고, 배포 이슈때문에 메인페이지 부분은
미완성으로 제출할 수 밖에 없었던게 조금 아쉽다.
사실 프로젝트가 아니라 학습의 연장선으로 팀단위 작업을 간단하게 하는 것에 지나지 않지만,
이런데서도 조금이라도 더 예쁘게 잘 만들고 싶다는 욕심이 계속 아른거린다.
디자이너가 있었다면? 아니면 내가 디자인을 조금 더 잘 알아서
시안이나 와이어프레임을 figma 같은 툴을 이용해서 조금 더 확실하게 짤 수 있었다면
같은 아쉬움이 남는다.
현업의 개발은 어떨지 아직 모르지만
이러한 소소한 토이 프로젝트 같은 경우에, 생각보다 style 작업이 오래걸린다.
로직짜는 시간 반, 스타일 작업하는 시간 반의 느낌이다. 물론 둘 다 좋아하지만.
로직에 대한 이해 같은 부분도 조금 아쉽다.
코드는 많이 보고 알면 알수록, 그러니까 숙련도의 문제라고 생각한다.
이 숙련도는 RPG 게임의 경험치 같은 것이라고 볼 수 있겠다.
처음엔 레벨이 낮으니까 쌓이는게 빨라서 레벨업도 빠르고 재밌지만
레벨이 점점 쌓이면 쌓일수록
'어? 분명 전에는 이정도 하면 레벨업 했는데..'
같은 느낌을 받게된다.
처음에 공부하던 간단한 코드가 좀더 어려운 코드, 좀더 어려운 로직으로 바뀌고
깊은 내용들을 공부하다 보면, 분명 재밌고 신나는 일이지만
레벨업에 대한 갈망도 그만큼 깊어지게 된다.
그러나 이 부분은 항상 그렇듯 시간이 해결해주는 문제이다.
경험치를 쌓는게 전처럼 쉽지 않을 뿐, 하루하루 경험치를 쌓다보면
분명히 레벨업을 할 수 있다.
시간은 항상 야속해서 나를 기다려 주지 않는게 가장 큰 문제다.
그 야속한 시간을 붙잡으려 몸을 혹사시키고 어제처럼 쓰러지기도 하고 하지만
그래도 결국 잡을 수는 없나보다.
몸이 망가지면 이 행복한 일들도 결국엔 할 수 없게 되므로 조금은 타협해 주는게 옳다.
저번주부터 항상 의욕만 앞서서 온전히 집중을 못하는 것 같다.
이번주부터는 backend 와 같이 협업을 하는데,
해결해야 될 문제가 산더미다.
그래서 조금 더 기대되는 것 같다.
