1. dangerouslySetInnerHTML

  • 리액트에서 element 내에 html 을 삽입할 때는 dangerouslySetInnerHTML 을 사용 할 수 있다.
  • dangerouslySetInnerHTML 을 사용하게 되면, 리액트 역시 해당 element 내의 내용이 동적이라는 것을 알게 된다.
  • 또한, 해당 노드의 자식들에 대해 버츄얼 돔과의 비교를 생략하여 성능적으로 향상된다.
  • 하지만 이름 그대로 dangrerously 하다. 바로 XSS(Cross-site scripting) 공격에 취약해질 수 있기 때문이다.

언제 사용해야할까?

  1. HTML 태그가 포함 된 데이터를 요소를 채워야 할 때.
const data = '안녕하세요 <b>이것은 굵은 글자</b>';

<div>{data}</div>;

위와 같은 경우가 있을 때 알다시피 <b> 태그는 제대로 삽입 되지 않는다. 이 때 dangerouslySetInnerHTML 을 사용 할 수 있다.

const data = '안녕하세요 <b>이것은 굵은 글자</b>';

<div
  dagerouslySetInnerHTML={{
    __html: data,
  }}
/>;

DOMPurify 와 같은 도구로 위험 줄이기

import DOMPurify from 'dompurify';

const App = () => {
  const data = `lorem <b onmouseover="alert('mouseover');">ipsum</b>`;
  const sanitizedData = () => ({
    __html: DOMPurify.sanitize(data),
  });

  return <div dangerouslySetInnerHTML={sanitizedData()} />;
};

export default App;

  • DOMPurify 와 같은 도구를 사용하면 alert 함수가 실행되지 않는다.


2. Module Federation

모듈 페더레이션 관련은..따로 포스팅을 할 예정이긴 한데, 짤막하게 기록해놓자면 회사 프로젝트에서 모듈 페더레이션을 사용하고 있다.

  • 모듈페더레이션은 웹팩에서 지원해주는 기능으로, 여러개의 어플리케이션을 각각 따로 빌드한 후에, 하나의 어플리케이션으로 동작하게 만들어준다. 그래서 말그대로 Module Federation, 모듈 연합을 의미한다.
  • 즉 A앱의 빌드 결과물에 B앱의 빌드결과물이 포함될 수 있다. (반대도 마찬가지)
    • 원래 웹팩은 단일 웹팩 빌드에 포함된 모듈들만 로딩 할 수 있다.
    • 하지만, 모듈 페더레이션은 여러 서버에 배포되어 있는 모듈을 하나의 애플리케이션에서 로딩 할 수 있도록 해준다.
  • 따라서 하나의 앱에 포함되어야 할 기능이 많아질 때, 해당 앱 자체가 뚱뚱해지는게 아니라, 여러 다른 외부 빌드 결과물을 가져올 수 있게 도와준다. (마이크로 프론트엔드..!)

회사에서 쓰는 경우는, 현재 타팀의 어플리케이션에 우리 팀의 기능이 들어가야 하는 경우가 있는데, 이 때 우린 모듈 페더레이션을 사용하여 우리팀에서 빌드한 결과물을 타팀 어플리케이션에서 로딩할 수 있게 한다.

이러면 관심사가 분리되어 코드 관리하기 매우 수월해진다.


3. Streaming SSR 이란

  • 서버사이드 렌더링 시, 전체 HTML 을 그려서 보내지 않고, 서버에서 앱의 컨텐츠를 스트리밍 처리 하여, 여러 조각을 나눌 수 있는 기능이다.
  • 노드 서버에서 HTML을 여러 조각으로 나누어서 생성되는 대로 클라이언트에게 전달한다.
    • 따라서, 해당 페이지의 HTML 사이즈가 크더라더, 일부를 미리 받아와서 그릴 수 있어서 TTFB(Time to First Byte) 시간이 감소한다.

장점

  • 기존에 SSR 은 전체 HTML 파일을 그린 후 클라이언트에게 전달했는데, 스트리밍 SSR 은 생성되는대로 HTML 을 조각으로 보내주므로, TTFB 가 더 빨라진다.
  • 네트워크 상태가 좋지 않아도, 잘 동작한다.
  • SEO 지원

단점

참고


4. 클린 코드 및..여러가지 대한 이곳 저곳에서 들은 것들

  • 제어 할 수 없는 것에는 의존하지 말기
  • 우연한 공통점인지, 본질적인 공통점인지 파악 한 후 추상화를 하기
  • 어쩌면 중복이 가장 베스트 일 수 있다.
  • 개발자가 계속 공부해야하는 이유는, 의사결정의 시간을 단축하기 위해서이다. 여기서 의사결정은 퀄리티 높은 코드를 작성 할 때 필요한 의사결정을 말한다. 즉, 일정을 지키며 퀄리티 높은 코드를 작성하기 위해서는 작업시간에 생기는 의사결정의 시간을 단축해야한다. 이는 꾸준한 공부로밖에 채워지지 않는다.

회고

  • API 명세를 받았을 때 의문인 것들을 그 때 그 때 여쭈어보지 않고 넘어가는바람에, 생각지못한 복병이 생겨서 백엔드 개발자분의 일을 늘려버렸다. 잘 모르겠는것, 엇 이건 왜이러지? 싶은건 그냥 명세 받으면 바로바로 여쭈어보자. 빠르게 소통하는 것이 좋은 생산성의 지름길이다.
  • 요즘 건강관리 습관을 정말 잘 실천 중ㅎㅇㅎ 물 많이 마시고 카페인 줄이고 등등!!