exta를 기존 nextjs 기반인 블로그와 문서에 적용하면서 불편한 부분을 수정해나갔다. (제작하고 있는 프레임워크 이름이 exta이다. 이 글에서는 편의상 계속 exta라고 부를 예정)

참고로 개발자 도구를 열어보면 알 수 있듯이, nextjs에서 exta로 전면 교체하는 데 성공하였다.

exta는 nextjs를 많이 참고하고 만들어서 사실 마이그레이션에 힘든 점은 귀찮은거 말고는 딱히 없다고 느꼈다. 다만 nextjs에 비해 기능이 너무 딸려서 이전과 같은 부드러움을 느낄 수 없었다. 이 부분은 고쳐야겠다고 느꼈다.

#페이지 이동 시 지연이 발생하는 문제

가장 거슬렸던 부분이 페이지 이동 시 느낌상 0.5초정도 지연이 발생하는 것이였다.
기존 nextjs를 사용할 때 preload의 뽕맛을 누렸다가 지연이 생기는 것을 보니 답답해서 참을 수 없었다.

지연이 발생하는 이유는 두 가지가 있다.
그것은 순수 페이지 자바스크립트를 다운로드할 때 발생하는 지연과, 페이지 데이터를 다운로드할 때 생기는 지연이다.

생각보다 쉽게 해결하였다.

자바스크립트 다운로드 지연은 rel="modulepreload" (중요한 모듈), rel="prefetch" (중요하진 않은데 곧 중요해질 것 같은 모듈)로 해결하였고,
데이더 다운로드에서 발생하는 지연은 그냥 코어 라우터에서 미리 다운로드 해두니 해결되었다.

이 사진에서 볼 수 있듯이 미리 다운로드하는 태그로 도배되어있는 것을 볼 수 있다. (이것도 수정의 수정을 통해 최대한 줄인 것이다) 근데 나는 이게 최선의 방법이라고 생각하진 않는다.

#Hydration 오류

무시해도 작동은 해서 나중에 해야지하고 미뤄놨는데, 생각보다 거슬려서 해결하였다.

There was an error while hydrating but React was able to recover by instead client rendering the entire root.

아무리 서버에서 렌더링된 HTML과 클라이언트에서 렌더링된 HTML을 비교해도 다른게 없는데 왜 hydration 오류가 발생하는지 궁금해서 찾아보니 props까지 똑같아야 hydration이 정상적으로 된다는 것을 알게되었다.

상상도 못한게 클라이언트에서 location이 변할 때 마다 재렌더링을 하기 위해서 넣어논 key attribute를 서버에는 그럴 필요가 없어서 안넣어놨는데 이게 문제가 된다는 것이였다.

이것도 서버 렌더링 부분 props에 key값을 추가해주니 해결되었다.

#해야할 것

어떻게든 작동만 되도록 코드를 짜다 보니 이제는 내가 무슨 코드를 짰는지 모르는 수준까지 와버렸다.
저번에도 미루다가 결국 코드를 처음부터 재작성하는 일이 있었기 때문에 이번에는 초기에 코드 리펙토링을 진행할 것이다.

물론 타 프레임워크는 메모리, 최적화 등에서 월등하게 좋겠지만 최소한 내 눈에 보이는 것은 타 프레임워크 못지않게 빠릿빠릿하게 작동해서 지금 상태에 충분히 만족하고 있다.
메인 라우팅, 서버 코드는 건들이지 않아도 될 것 같고, overlay같은 좀 있는 것에 감사해야할 사치스러운 기능들을 추가할 것이다.

그리고 이거는 허망된 꿈이긴 한데, 얼마전에 만든 swc 기반 서버용 번들러를 여기 적용시키고 싶다.
아직은 esbuild를 버릴만큼 저 swc 기반 번들러를 사용해야할 상황이 안나와서 못쓰고 있는데, 나중에 쓸 일이 있었으면 좋겠다.