2024.03.11 TIL #new RegExp() #Next.js_SSR_vs_CSR

# new RegExp() 란?

- 문자열 패턴을 정규식 객체로 변환하는 기능

왜 사용하게 됐는가?

 let babbling = ["ayaye", "uuu", "yeye", "yemawoo", "ayaayaa"]; 

 let heCan = ["aya", "ye", "woo", "ma"]; 

이라는 두 배열이 있을 때, babbling의 요소 중 heCan 배열의 요소로 바꾸고 싶었다.

반복문을 사용하여 replace() 함수를 사용하려고 했는데, replace 함수를 사용할 때 인자가 동적으로 바뀔 때는 단순히

 bab.replace(heCan[i], ""); 

이렇게만 하면 안 되고, 인자를 정규식으로 바꿔줘야 한다. 

 bab.replace(new RegExp(heCan[i]), ""); 

이렇게 정규식으로 바꿔주면 된다. 

그런데 부수적인 효과로 이렇게 정규식을 사용해서 replace() 함수를 사용하면, 일치하는 첫 번째 요소만 찾아서 바꿔준다.

즉, babbling의 요소 중 하나가 만약 "woowoo"이고, heCan[i]가 woo인 경우, 앞에 "woo"만 지워주기 때문에 반환되는 값은 "woo"가 된다. 
만약 일치하는 모든 내용을 교체하려면, 

 bab.replace(new RegExp("woo", "g"), "") 

이렇게 "g" 플래그 -> global 를 사용하여 전역적으로 모든 일치하는 패턴을 교체해주면 된다. 

 

# Next.js에서 SSR(Server-Side-Rendering) 과 CSR(Client-Side-Rendering) 의 차이

SSG, ISR은 비교적 다른 것들과 비교하기 쉬웠는데, SSR과 CSR의 차이가 조금 헷갈렸다.

- 개념적인 것은 워낙 정보가 많은데, 내가 생각하는 가장 큰 차이점은 렌더링을 수행하는 주체와 시기 + SEO 라고 생각했다.

- 공통점: 렌더링의 트리거는 SSR과 CSR 둘 다 클라이언트가 요청할 때마다 트리거 된다.

	SSR	CSR
렌더링 주체	서버 - 서버가 완전한 HTML 생성 후 브라우저로 보냄	브라우저 - 초기 요청에 HTML, CSS 및 JS 파일만 포함 -> 브라우저에서 JS를 실행하면서 렌더링
렌더링 시기	- 자바스크립트 실행순서와 브라우저 최적화(브라우저 캐싱, 돔트리 생성 시)에 따라 CSR에 비해 TTV는 짧지만, TTI는 긺	- SSR에 비해 TTV는 길지만, TTI는 짧음
SEO	- 이미 렌더링된 페이지를 제공하므로   SEO에 유리	- 초기에는 root의 div html 요소만 있으므로 SEO에 불리
사용처	- TTV가 짧아야 하는 페이지 또는 컴포넌트(ex. 상품상세페이지, 로그인페이지) - 빠른 검색이 필요한 페이지(ex. 블로그 게시물)	- 데이터가 계속 바뀌는 컴포넌트 또는 페이지(ex. 마이페이지)

 

CSR에서 TTI가 빠를 수 있는 경우

 

• 자바스크립트 코드 최적화:
  • 불필요한 코드 제거, 효율적인 알고리즘 사용
  • 코드 분할 및 로딩 최적화
• 브라우저 캐싱:
  • 자바스크립트 파일 캐싱을 통해 로딩 시간 단축
  • 캐시 무효화 전략 적용
• 사용자 행동:
  • 사용자가 페이지 내 특정 영역에만 집중하는 경우 TTI 지연 크게 영향을 미치지 않음