server와 client component를 처음 사용하게 되면서 사용할 수 있는 기능에 제약이 있는 것을 잘 알지 못했다.
백엔드에서 데이터를 가져오는 로직을 위해 async/await도 써야 하고 (server component 기능) router를 사용하고 함수도 내려줘야 하는데 (client component 기능) 모두 사용하려니 계속 에러가 나서 헤맸고 매우 답답했다.
전 회사에서라면 10분내로 답 안 나오면 바로 질문하라고 해서 사수님의 도움을 받으며 해결했을테지만 멘토링에서는 멘토님이 끝까지 찾길 추천하셨고 아니면 따끔하게 지적받기에 계속 찾아봤다.
꽤 오랜 시간이 걸렸고 포기하고 멘토님께 그냥 질문드려 해결하고 싶은 순간들도 있었으나, 돌아올 답이 무엇인지 알 것도 같고 그냥 한 번 찾아보았다. 개발자가 스스로 찾는 것도 중요하기 때문이다. (회사에서는 시간 관계 상의 이유로 빠르게 질문하는 것을 권유한 것으로 안다.)
아마도 에러메세지를 쳤고 원어를 해석해내는 고통을 견디면서 stackoverflow에서 우연히 use를 사용하면 해결 가능하다는 것을 봤고 그것이 내가 알지 못한 hook이며 근래에 추가 되었다는 것을 알게 되었다.
그래서 use hook에 대해 공식문서와 블로그에서 어떤 기능을 하는 hook인지 찾아보았고 내가 원하던 기능을 하는 알맞은 function임을 알았다.
뿌듯했고 성취감을 느꼈다. 얼마 전, preview 구현하면서도 이번에도 (비록 오랜 시간이 걸렸지만) 스스로 해결해냈다.
단순히 끝날 줄 알았던 update와 delete였는데 새로이 업데이트된 기능으로 구현하는데 차질이 많았고 스스로 해결하려다 보니 오랜 시간이 걸렸으나 뿌듯했다. 얻은 점은 조금씩, 스스로 문제 해결하는 방법을 찾는 것 같다는 점이다. 에러 로그를 이해하고 부족하면 에러 로그를 검색하고 (원어라 고통스럽지만) issue탭이나 stackoverflow에서 나와 비슷한 문제를 겪는 이들이 있는 것을 확인하고 그들이 어떻게 해결해내고 있는지 알 수 있다.앞으로도 이런 방식을 조금 더 빨리 실행해서 스스로 해결할 때 속도를 높이는 것이 좋을 것 같다.
혼자 할 수 없어서 모르는 부분은 대부분 chatGPT에게 물어가면서 답을 구하거나 아니면 전에 봤던 레퍼런스 영상을 참고했던 것 같다.
아무래도 백엔드는 잘 모르다보니 이 방법 말고는 대안이 떠오르지 않았다.
무척 빡셌던 것 같고 프론트엔드 개발자로서 ROI가 뛰어난지 솔직히 잘 모르겠다.
하지만 그래도 전에는 잘 모르겠다는 느낌이 들었던 백엔드 로직 구현 flow에 대해서 조금 더 이해할 수 있었다. (스키마를 작성하고 api fetch를 하면 된다
는 비교적 간단한 로직인데 그래도 전엔 어려웠었다.)
그리고 앞으로 백엔드 개발자와 소통할 때 전보다는 더 높은 이해도를 가지고 대화할 수 있지 않을까 싶다.
또한 계속 보다보니 문법이 조금씩 익숙해져가는 느낌이 들었다. 예를 들어 for문을 돌려하기보다는 자체적인 문법 (ex. find 등) 을 통해 (난 잘 모르니 그런 문법이 보이면 chatGPT에게 문법을 찾아 리팩토링 해달라고 했다) 보다 가독성 좋게 만들 수 있었다.
아 그리고 백엔드를 해보니 크로스 체크하는 게 좀 고단했다. 이를테면 하위 스키마인 article을 바로 상위 스키마인 카테고리 중 다른 카테고리로 이동 시킬 때, article만 바꾸면 category 스키마에 자동 반영 될 줄 알았는데 다 하나하나 수작업으로 하는 게 무척 번거로웠다. 이 부분이 내가 방법을 못 찾은 건지 뭔지 모르겠으나 뭔가 코딩 답지 않다는 느낌이 들었다. ㅎ
아무튼 분명 배운 점은 있었다. 다만 높은 ROI가 나올지는 모르겠을 뿐.
아무튼 무척 고생했던 몇 일이었다. 잘 모르는 백엔드를 구현하려고 애쓴 나에게 고생했다는 칭찬 한 마디 하고 싶다.
아, 그리고 카테고리를 굳이 굳이 미리 넣은 이유는 내가 velog를 하면서 카테고리를 엄청 유용하게 잘 썼기 대문이다. 앞으로도 잘 쓸게 분명해서 꼭 넣고 싶었는데 api spec이 바뀌면 불편하니 미리 넣어주고 싶었다.
막상 해보니 그렇게 많이 바뀔 거 같지는 않지만 .. 그래도 수고 많았고 속이 다 시원하다. 어휴~
드디어 category 백엔드 로직이 끝났다. 프론트도 해야 한데 디자인은 빼고 하니 그래도 속도는 좀 나겠지. 수고 고생 모두 많았다 나 자신 !!!!!!!!!!!!!! 👍
onInput은 onChange와 다르게 e.target.value로 값을 얻을 수 없었다. ts에서 에러가 나기 때문이다.
그래서 일단 ts에러가 나지 않는 currentTarget까지 입력한 다음.. 구글링도 해보고 chatGPT에게도 물어봐도 답이 제대로 나오지 않던 차에 직접 property를 쭉 보다가 textContent를 발견했다.
결국 제대로된 방법을 찾아낸 것인데 이런 식으로도 문제를 해결할 수 있다는 것을 배웠다.
어떻게 카테고리 이름을 바로 변경할 수 있을지 찾아보던 차에 개발자 도구로 벨로그를 보니 contentEditable의 값이 계속 변경되는 것을 알 수 있었다.
벨로퍼트 님이 만드신 사이트 이기 때문에 더 신뢰도가 높았고 그래서 나 또한 도입하게 되었다.
그래서 onInput도 처음으로 알게 되었다.
새로 알게된 2가지의 속성 모두 흥미로웠다. 특히 h1태그에서 바로 편집 가능한 버전으로 바뀌는 contentEditable 속성은 혁신이었다.
굿 👍
시맨틱 태그에 유의해서 작성하고자 노력을 좀 했다.
아주 잘 작성한지는 모르겠으나 mdn 등을 살피며 최선을 다해 작성했다.
헷갈리는 부분도 있었다. 이를 테면 section 내부에 제목이 들어가야 하는지, article 아래에 article이 귀속될 수 있는지 등 말이다.
계속해서 레퍼런스를 찾아보면서 작성했다.
그랬더니 seo 가 100점이 나왔다. 뿌듯하다.
매우 긴 과정이었다. 카테고리가 이렇게 길게 갈 줄 알았다면 나는 카테고리를 추가했을까?
패기롭게 시작했는데 시간이 생각보다 많이 걸렸고 백엔드 쪽에서 버벅 거리는 것이 많았고 기획적인 측면에서도 어려움이 있었던 것 같다.
특별한 테크닉을 쓴 것 같지는 않은데 기존에 작성되어 있었던 타입을 싹 고치는 것이 꽤나 어려운 작업이었던 것 같다.
수정했던 방법은 그냥 다 찾아보고 많이 쓰이는 순서대로 정리했고 그 다음에 겹치는 것들은 따로 Interface로 만들어 뒀다.
그 외에는 모두 chat GPT와 구글링으로 비교적 간단히 해결할 수 있었던 것 같다.
별거 없어보이는 트러블 슈팅이지만 한 PR을 가지고 1~2주 정도를 씨름한 것 자체가 트러블 슈팅이었던 것 같다. 아직 Read와 DELETE 단계가 남았는데 그 과정까지 좀 더 힘내서 해내고 싶다.
화아팅 ㅠ
interface를 import하다가 순환참조 에러 (에러 문 : Error: Dependency cycle detected. import/no-cycle
)이 발생했고 어떻게 해결해야 할지 한참 고민했었다. (아주 오랜 시간은 아니였지만..)
chatGPT에서는 의존성을 최소화 하라는데.. 그걸 나도 하고 싶은데 구체적인 답안이 나오지 않아서 답답했었고 ‘순환 참조’ 등을 검색하다가 에러문을 직접 구글링 해보니 누군가 비슷한 에러를 겪은 것을 github issue에 올렸고 거기서 이모지(👍)가 가장 많은 것을 찾아보니 import type
을 사용하면 해결된다고 적어둔 것을 발견했다.
단순히 type
하나 추가한다고 될 까 했는데 해결이 되었다.
비교적 간단했고 역시 구글링에서 나처럼 삽질을 해본 사람들의 해결방안을 확인하는 것이 베스트라는 것을 느꼈다.