-
Notifications
You must be signed in to change notification settings - Fork 2
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
[Feat] 환경변수를 활용한 동적 메타태그 구현 #455
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨습니다~~~~ :)
말씀해주신 거 처럼 현재 isMakers 부분을 api res가 아닌 env mode로 구분해주면 너무 좋을 거 같네용 :)
import { Helmet } from 'react-helmet-async'; | ||
|
||
const Head = () => { | ||
const isMakers = import.meta.env.VITE_TEAM_NAME.includes('makers'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const isMakers = import.meta.env.VITE_TEAM_NAME.includes('makers'); | |
const isMakers = import.meta.env.MODE === 'makers'; |
mode를 makers로 설정해줬기 때문에 이를 적용하면 좋을 거 같아요
환경변수 하나 더 추가하기 보다요!
물론 cloudflare에서 build 설정을 yarn build:makers, yarn dev:makers로 바꿔야 합니다!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아하 너무 좋은 것 같습니다 ~~!!!!
대신 MODE를 사용할 경우 로컬에서도 항상 yarn dev가 아닌 yarn dev:makers 이렇게 해주어야 하는데
그럼 차라리 저희가 .env (로컬 환경변수)를 어차피 메이커스 버전으로 다 사용하기로 했으니까
아예 디폴트 yarn dev 실행을 vite --mode makers 로 실행시키는 것은 어떠신가요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아항 좋은 거 같습니다~~ 그건 여기서 수정할게요 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
완전 좋습니다~ ~ 주용오빠 확인하면 머지할게요 !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
넹~ develop에 merge 해주세여 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아 그리고 const isMakers = import.meta.env.MODE === 'makers'
로 바꾸는 건 이 pr에서 수정 부탁드려요~~~
앞서 말씀드렸던 여기선 빌드 명령어를 수정할게요 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨습니다 !! 🚀🚀🚀
Deploying sopt-recruiting-frontend-test with Cloudflare Pages
|
…ing-frontend into feat/#454_dynamic-head
Related Issue : Closes #454
🧑🎤 Summary
#447 에서 말씀드렸던 고민을 한번 해보았어요
해결책으로 환경변수를 활용해보자!를 떠올려보았습니다
🧑🎤 Comment
하나의 레포에서 솝트버전/메이커스버전 두가지를 분리배포하게되면
그동안 두 레포에서 하드코딩하던 index.html의 메타태그들은 어떻게 해야할까? 라는 문제가 생겼어요
첫 제안은 main 브랜치에서 release/sopt 브랜치를 분기해서
배포 브랜치를 분리해서 관리하는 방식이었어요
main 브랜치는 메이커스용 배포본에, release/sopt 브랜치는 솝트용 배포본에 연결하는거죠.
그러구나서 그동안 솝트용 레포(fork 레포)에서 작업하던 솝트 전용 하드코딩 방식을 release/sopt 브랜치에서 진행하면
기존 방식대로 무난하게 메타태그들을 분리시킬 수 있겠다 싶었어요
하지만 언석님의 의견은 배포브랜치를 분리해서 관리할 경우 브랜치를 관리하기가 귀찮아진다는 우려점을 말해주셨고
저도 여기에 매우 동의했어요 두 브랜치에서 각기 다르게 하드코딩하는게 많이 짜치는 방식이라고도 생각했고...
그래서 다른 방식을 고민해봤는데요, 결론부터 말하자면 핵심은 환경변수입니다.
⛄︎ react-helmet-async 사용했던 방식 복구
이전에 동적 메타태그를 구현하고자 react-helmet-async을 사용해서 구현했었는데요,
메타태그가 정상 작동하지 않아서 그냥 롤백시켰던 적이 있었습니다.
그때 코드를 다시 살리고 라이브러리도 다시 설치해주었어요. (약 80kb인데 효과 > 비용 이라고 생각)
⛄︎ 그럼 이전의 실패 원인은?
위에 링크해둔 PR 참고하시면 알 수 있는 점이
당시에 메이커스용 메타태그 / 솝트용 메타태그를 동적으로 로드하기 위해
context로 관리해주던 isMakers를 가져와서 이에 따라 조건부 렌더링을 해주었어요.
그런데 context로 관리하는 isMakers는
/latest
API 통신해서 get해온 응답 중name
의 값에 makers 문자열이 있는지 여부에 따라 결정되는 값이라결국엔 서버 통신이 이루어진 뒤에야 유의미한 값을 가질 수 있어요.
그렇기 때문에 가장 마지막에 이루어지는 서버통신 전에 만들어지는 메타태그들은 정상적으로 조건부 렌더링이 되지 않았던거죠
그렇다면 빌드타임때부터 IsMakers의 값을 결정지을 방법이 뭐가있을까? 하다가 생각한게 환경변수였어요
처음엔 isMakers 여부처럼 뭔가 비밀(?)도 아닌 값을 환경변수로 관리하는게 맞을까? 생각했는데,
오히려
VITE_
로 네이밍되는 환경변수들은 어차피 번들에 다 값이 포함되어서 보안성이 떨어진다고 하더라고요?또 환경변수는 말그대로 실행되는 환경에 대한 변수니까, 배포 환경 분리의 기준인 솝트 / 메이커스 분류값도 충분히 환경변수로 관리해줘도 괜찮은 친구같다! 라는 생각이 들었습니다.
⛄︎ 실행에 옮기다
그래서 아래처럼 env에 추가해줬고요
기존에 useContext로 가져오던 isMakers 식을 이렇게 바꿨어요
🩸중간 트러블 슈팅 : makers 이미지만 왜 안떠
아래 스샷에서 보이다시피 makers og 이미지만 안뜨는 문제가 있었어요.
url로 접속하면 잘만 뜨는걸 보면 이미지 자체의 문제는 아니고,
규격 때문일까 뭘까 이것저것 시도해봤는데,
결론은 현재 저희 recruiting.sopt.org 도메인이 다운돼서 이미지가 안뜨는 것이라는 결론을 내렸습니다.
local에서 테스트하고있는데 recruiting.sopt.org가 뭔 상관? 이라고 생각할 수 있는데
현재 og url을 이렇게 넣어주고 있는데
오픈그래프 크롤러가 이 og url을 기준으로 크롤링을 하기 때문에, og url이 비정상적인 링크일 경우 다른 meta tag에도 영향이 간다고 하더라고요?
그래서 그런 가설을 세워보았습니다.
아마 맞을 것 같은데 이 부분은 나중에 도메인 복구 되면 확실히 확인해볼 수 있을 것 같아요
🧑🎤 Screenshot & 결과
localhost opengraph checker 크롬 익스텐션을 활용해서 og 확인해줬어요
기존 방식대로 테스트돌리면 이렇게 sopt 관련 og가 보여요.
isMakers가 Undefined일테니 당연해요
방식을 수정한 후
이렇게 Makers 여부에 따라 title과 description이 모두 잘 들어가는 것 확인했습니다!
마지막 첨언...
환경변수로 동아리 종류를 관리하는 위의 방식이 채택된다면
현재 useDate에서 계산해주고 있는 isMakers 방식도 위의 방식으로 바꿔줘도 될 것 같아요
환경변수는 빌드될 때 채워지지만 현재 방식은 서버 응답을 모두 받은 후에야 채워지니까
조금이라도 성능에 도움이 되지 않을까요?
그리고 뭔가 상황에 따라 변할 수 있는 값이 아니라, 배포 환경에 따라 영구적으로 고정적인 값이니까
서버 응답에 의존하기보다 환경변수에 의존하는게 조금 더 적합하지 않나. . 하는 생각이 들었습니다
이상입니다 🙇🏻♀️