1)
ref.current?.setAttribute(
"style",
`--top: ${somePositionYValue}px;
--left: ${somePositionXValue}px;`
);컴포넌트 단에서 위와 같이 쓰고 scss 에서
top: var(--top);
left: var(--left);위와 같이 해주면 그대로 적용이 된다. scss를 css-module이랑 쓰면서 styled-component의 css control 간편성(?)이 그리웠는데, 이런식으로 css를 컨트롤 할 수 있는 방법이 있었다. 결론은 내가 귀찮아서 안찾아본거 였다..
2) createPortal 넌 누구냐!
: createPortal은 간단하다(?). 말그대로 portal을 하나 열고 컴포넌트 혹은 JSX 를 심도록 도와준다. 예를 들어, UX 상 거의 무조건 최상단에 위치하는 modal의 경우 index.html 파일의(public 내의) <div id="root" /> 에 끼워넣는게 편하다. zIndex 세팅으로 zIndex: 999999; 이런식으로 할수도 있겠지만,, 그럼 그것보다 위에 있는건? 9999999 이렇게 하지뭐! 느낌이 되기에 pass. 이렇게도 쓸 수 있고, 본래 목적 자체는 앞서 말했듯이 특정 태그 등에 원하는 컴포넌트 or JSX를 끼워넣는 용도라고 할 수 있다. 근데 생각해보면 직접 끼워넣어서 개발하면 되는거 아닌가? 할 수 있지만, 모듈을 만든다는 측면에서 생각했을 때 children으로 혹은 prop으로 내려준 컴포넌트에 대해서 특정 parentEl에 특정 컴포넌트를 portaling?(심고 싶다면) createPortal을 쓰면 매우 간편하다. 그리고 이런 용도로 쓰는 것이 createPortal이다.
3) useMemo 확실하게 짚고 넘어가기
: useMemo를 성능 최적화 용도로 자주 쓰는데,
useMemo(()=>{some Logics}, [deps]);위와 같이 쓴다고 했을 때 Some Logics가 복잡한 연산이라고 할 때 매번 리렌더링이 일어날 때마다 이 연산을 하기가 벅찰 수 있다. 따라서 deps에 있는 값에 변동이 있을 경우에만 재연산을 하도록 하는게 useMemo이다. 따라서 이건 렌더링 최적화 툴은 아니고 연산 최적화 툴이라고 할 수 있다.
이에 더하여 useMemo를 남용(?)해서는 안된다.
const expensiveCalculation = (num) => {
console.log("Calculating...");
for (let i = 0; i < 1000000000; i++) {
num += 1;
}
return num;
};위와 같이 시간 복잡도(?) 측면에서 높은 복잡도를 가진 연산에 써야 이 최적화를 제대로 누릴 수 (?) 있다. 간단한 연산에 useMemo를 남용하게 되면 deps 내에 쓴 값이 변했는지를 비교하는 ObjectIs 연산에 오히려 더 높은 비용이 들어가 최적화의 의미가 퇴색될 수 있으니 주의해야한다(공식 문서에도 This optimization helps to avoid expensive calculations on every render. 라고 비싼 연산?을 최적화한다고 써져있다).
4) TIL에는 안맞게 이전에 알게된 내용이긴 하지만 semantic tag로서 nav 태그 안에는 a 태그와 같이 특정 페이지로 보내는 링크 태그와 같은 것들이 들어가야한다. 페이지 네이션이나 화살표 등의(이전, 다음 버튼 등)을 넣는 곳이 아니다!.
