Growth Log : by dpwls

Appearance

0708 ​

RealWorld ​

getInitalProps의 또 다른 단점과 getServerSideProps ​

  • profile 페이지에서 useRouter를 활용해 클라이언트 측에서 사용한다는 이유로 처음에 데이터를 페칭해올때만 서버에서 하고 나머지는 클라이언트 단에서 처리한다는 특징을 갖는 getInitalProps를 사용했다.
  • 근데 404 페이지를 별도 페이지로 분리하는 과정에서 에러코드가 뜨는게 아니라 계속 user_id를 못 찾는다는 오류만 반환을 했다.
  • 가만 생각해보니 오류를 서버딴에서 처리하려고 하니 발생하는 문제였다. 근데 그렇다고 useEffect로 클라이언트딴에서 오류를 처리해주자니 이는 안티패턴이다.
    • Q, 왜 클라이언트딴에서 오류를 처리하는게 안티 패턴인가?
    • A. 클라이언트 단에서 404 오류를 처리하면 SEO에 문제가 생긴다. 검색 엔진이 페이지를 크롤링할 때 서버는 200 상태코드를 반환하고, 클라이언트에서만 404 상태를 인식하게 된다.
      또한 사용자 경험 측면에서도 페이지가 먼저 렌더링된 후 오류 상태로 바뀌는 깜빡임 현상이 발생할 수 있다.
  • 그래서 getServerSideProps를 사용하는게 여러모로 맞는 이유라 생각했다.
  • 근데 서버사이드에서 오류를 처리할 때 계속 아래와 같은 오류가 발생했다.

Error: Additional keys were returned from getServerSideProps. Properties intended for your component must be nested under the props key, e.g.:
return { props: { title: 'My Title', content: '...' } }
Keys that need to be moved: notFound.

  • notFound를 key로 설정하라 해서 했더니만 해도 똑같은 오류가 발생하는거 아니겠는가..
  • 그래서 검색해봤는데 스택오버플로에 이런 글이 있었다.
  • Additional keys were returned from getServerSideProps. Return notFound object from getServerSideProps
  • next.js v10 이상부터 지원하는 기능이랜다. 아니 근데 왜 오류 설명에는 notFound를 설정하라고 하는거지?
    • Q. 에러 페이지는 최신 버전을 기준으로 맞춰지는건가?
    • A. Next.js의 에러 메시지는 최신 버전을 기준으로 제공되는 경우가 많다고 한다.
  • 그래서 아래와 같이 try catch로 에러가 발생하면 res의 header를 덮어 씌우는 형태로 오류를 처리했다.
ts
res.writeHead(302, { Location: '/404' });  
res.end();  
return { props: {} };
  • 상태코드 302번은 임시 리다이렉트(Found)를 의미한다.
  • 왜 이렇게 처리했냐면, 그냥 return { props: { statusCode: 404 } } 로 처리하면 바로 404 에러를 발생시키기 때문에 커스터마이징한 404 페이지가 보이질 않는다.
  • 고로 사용자를 404 페이지로 이동시키기 위해 3xx 리다이렉트 상태코드를 썼다. 301번을 쓰자니, 언젠간 생길 수도 있는 유저고, 포스팅이기 때문에 302번이 낫다고 생각했다.
  • 참고 자료: RFC: Returning redirects from getServerSideProps / getStaticProps

tanstack query ​

removeQueries vs invalidateQueries ​

기능removeQueriesinvalidateQueries
역할캐시에서 완전히 삭제캐시 무효화 (재요청 트리거)
결과캐시 데이터 자체를 제거함다음 컴포넌트 리렌더 시 자동으로 refetch
사용 상황데이터를 완전히 버리고 싶을 때데이터가 변경되어 다시 받아야 할 때
Refetch 발생XO
  • 아티클 수정, 좋아요: invalidateQueries
  • 아티클 삭제: removeQuries

js 기초 ​

문자열 뒤집기 ​

js
let string = "Hello! Welcome to my Velog. Ask me anything.";

function reverseBySeparator(string, separator){  
	return string.split(separator).reverse().join(separator);  
}

console.log(reverseBySeparator(string, "")); // 전체 문장 뒤집기  
console.log(reverseBySeparator(string, " ")); // 스페이스(단어) 기준 뒤집기
js
function reverseString(str) {  
  let reversed = "";  
  for (let i = str.length - 1; i >= 0; i--) {  
    reversed += str[i];  
  }  
  return reversed;  
}

console.log(reverseString(string)); // 전체 문장 뒤집기

코테와 관련해서 느낀점 ​

코테 때문에 좋은 기회를 놓친 게 속상하다.
좀 더 다양한 알고리즘을 봤어야 됐는데 구현만 풀었던 것 같다.

실상 구현만 풀었다고 하더라도 실력이 올라가야 됐는데 그렇지도 않은 것 같다.
한 시간 정도 고민하다가 안 풀리면 정답을 봤는데 이 방식이 잘못됐던 것 같다.
아직 많이 부족하다는거겠지.

반개월간 잔디밭이 쌓이는 재미만 즐기며
1일 1풀 이라는 행위에만 집중해서 문제를 푼 것 같다.
이러면 안 됐는데 ㅎ

그래도 반개월 동안 꾸준히 풀려고 노력한걸 높게 사자~
고 생각하고 싶지만....
노력한 과정을 알아주기란 쉽지 않으니 더 노력해서 성과로 나타내는 수 밖에 없다.

일단 이번 기회로 코테 환경을 경험해볼 수 있어서 너무 좋았다.
감독이랑 이런게 어떻게 이뤄지는지 볼 수 있었으니까..
고것만으로도 만족!

그리고 오늘 아침에 우연치 않게 이 영상을 보게 됐는데

이분께서 말씀해주신 공부법대로 다시 차근차근 공부해봐야겠다.
(물론 내가 저렇게 빅테크를 가고 싶다는건 아니고.. 물론 가면 좋겠지만 ^^ 공부법이 좋은 것 같아서)

7월 알고리즘 공부 계획 ​

1. Programming Interviews Exposed ​

  • chap3 ~ 8, 13에서 graphics 부분 제외
  • chap 9, 10, 16은 참고

2. Cracking Coding Interview ​

  • chap 1, 2, 3, 4, 5, 8, 9
  • chap 7은 디자인 패턴
  • chap 18은 스레드
  • 도저히 못 풀겠으면 솔루션 보고 이해하고 다시 풀어보는 과정 까지 반복하기
  • 그래프 이해 영상
  • 알고리즘 영상

cf. 목표 ​

매 챕터마다 노트에 정리하고 블로그에 포스팅하기

뭐 AI 때문에 채용 과정에서 코테가 사라지든 말든
코테를 풀다보면 언어 기본 문법을 외우게 되고 구조도 정리되기 때문에
안 좋은 점은 없는 것 같다

코테를 겁내하지 않을 날 까지 화이팅 해보자.........
나도 히라마사처럼 코딩 잘 할래..ㅠ