Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Fix] 동적 meta tag pre-rendering #342

Closed
lydiacho opened this issue Aug 2, 2024 · 3 comments · Fixed by #414
Closed

[Fix] 동적 meta tag pre-rendering #342

lydiacho opened this issue Aug 2, 2024 · 3 comments · Fixed by #414
Assignees

Comments

@lydiacho
Copy link
Member

lydiacho commented Aug 2, 2024

🦎 TODO

현재 동적 메타 태그가 undefined 이슈로 제대로 먹히지 않고 있는데, pre-rendering을 돕는 라이브러리를 사용해서 이를 해결하고자 함

@lydiacho lydiacho self-assigned this Aug 2, 2024
@eonseok-jeon
Copy link
Member

eonseok-jeon commented Aug 17, 2024

흠 근데 지금 상황이
makers 모집 -> sopt-recruiting-frontend 이용
sopt yb,ob 모집 -> sopt-recruit-frontend 이용 중이고

일정 상 앞으로도 makers와 ob 모집 기간 겹칠 거 같아서
이대로 유지될 거 같은데
그렇다면 위와 같이 동적으로 처리하기 보다
각각에 레포에 하드코딩으로 각각 적용 해주는 게 낫지 않을까? 싶은데 어떻게 생각하시나요

추가로 하나의 이슈를 해결하기 위해 2개의 라이브러리를 설치하는 것과 관련해서 이로 인해 발생되는 트레이드오프를 뛰어넘는 장점이 있는가에 대해서는 의문이 들긴해요
리크루팅 사이트는 seo 최적화가 필요한 것이 아니고
title을 35 and sopt 지원서 대신 모든 기수를 아우를 수 있는 sopt 지원서라고 설정한다고 해서 사용자가 이게 예전에 사용되던 지원서 페이지인가? 할 거 같진 않아서요!

하지만 개발 공부 하는 입장에서 해당 이슈를 새로운 기술을 도입하여 해결해보고 싶어 그런 거라면 저는 완전 지지합니다! :)

@lydiacho
Copy link
Member Author

lydiacho commented Aug 17, 2024

makers와 sopt를 현재와 같은 형태로 분리하여 배포한 현 상황에 있어서 저도 하드코딩이 더 적합하다고 결론 내렸습니다 :)

다만 동적 메타 태그를 구현하고자 했던 이유는, 새로운 기술을 도입해보고 싶었던 것이 아닌

  • makers 여부 / 기수에 따라 다른 OG태그를 제공하는 것이 저희가 정했던 명세여서 해당 구현을 급히 종결내야 하는 상황이 아닌 이상, 이것이 사용자에게 크리티컬한 부분인가를 저희가 따지는 것이 아니라 하기로했던 대로 최대한 구현해보는 것이 맞다고 생각했음
  • 리크루팅 사이트는 SEO 최적화가 불필요하기 때문에, Next JS 등의 온전한 SSR 마이그레이션이 아닌, 부분적 pre-rendering을 도입할 수 있는 선택지들에 대해 알아보았음
  • 라이브러리를 무엇을 사용할지 정하지 않은 상황에서 무조건 라이브러리 설치로 발생하는 트레이드 오프를 뛰어넘을 장점은 없다라고 판단하기는 섣부르다고 생각했음.
  • 각 레포에 SOPT / Makers에 따라 하드코딩하는 방식을 다른 솔루션을 알아보지 않고 섣불리 택하기엔, 현재 코드 전반에서 Makers / SOPT에 따라 조건부렌더링을 해주고 있기 때문에 그 패턴의 일관성을 유지하는 것이 바람직하다고 생각했음.

위와 같은 이유들 때문이었어요
그래서 하루정도 투자해서 알아보았는데,
react-snap, prerenderer 등의 라이브러리 등을 처음에 고민했으나 말씀하신 것처럼 해당 이슈를 해결했을 때의 효과 대비 더 큰 비용을 필요로하는 의존성 설치는 지양하고자 하여 제치고, vite plugin을 활용하는 방식이나 cloudflare 자체적으로 제공하는 built-in prerender 기능이 없는지 알아보았어요. (netlify는 built-in prerendering 기능을 제공하고 있더라고요) 그런데 마땅한 솔루션이 없어서 결론적으로는 하드코딩하는 것이 적합한 상황이겠다고 생각했습니다

모쪼록 어제 이모저모 고민해보다가 저 또한 하드코딩이 현재로서 가장 효율적인 선택지라고 생각했는데 고민한 내용에 대해서는 공유드리는게 좋을 것 같아서 첨언했습니다
하드코딩으로 작업해서 PR 올리겠습니다!

@eonseok-jeon
Copy link
Member

헉 자료 찾으시느라 고생 너무 많으셨습니다ㅜㅜ
무슨 말인지 잘 이해했습니다!!! 의견 정리해주셔서 감사드립니다 🙇🏻‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants