My Boundary As Much As I Experienced

테스트에는 유닛테스트와 인터그레이션 테스트, e2e테스트가 있다. 유닛테스트는 jest, 인터그레이션 테스트는 react testing library로 많이 한다. (jest로 인터그레이션 테스트도 가능하긴 함.) CRA를 하면 react testing library와 zest를 기본적으로 깔아줌. 파일 이름 컨벤션은 App.test.js 식으로 많이 짠다. in App.test.js import { render, screen } from "@testing-library/react"; import App from "./App"; // learn More라는 텍스트가 있는지 확인하는 테스트 // 이걸 테스트할 필요가 있나? test("renders learn More link", () => { // 맨처음..

useContext란? 프롭스 드릴링(프롭스가 하위 컴포넌트로 파고파고파고파고 또 파고 들어가는 현상)을 피하고 싶을 때 쓰는 문법. props 체이닝이 없이도 값을 전달하고 싶을 때 사용한다 context 설정법 api라던가, store, context같은 폴더에 파일을 만들어서 따로 관리한다. React 라이브러리를 import하고, createContext 메소드에서 관리하고 싶은 상태값을 입력(구독)한다. import React from "react"; const AuthContext = React.createContext({ isLoggedIn: false, }); export default AuthContext; 그런 다음에, App.js 같은 전역적으로 뿌릴 수 있는 곳에서 를 이용해 제공한..

useReducer란? useReducer는 상태를 관리하는 또 다른 방식이다. useState의 경쟁자?라고 보면 된다. 그렇다면 useReducer와 useState는 무엇이 다른가? 흔히 쓰는 useState는 '필요한 state만큼 생성해서 개별 관리'하였다. 그러나 useReducer는 여러 state가 존재해도 하나의 로직으로 다 관리한다. '중앙화된 state묶음'이라고 보면 된다. 이렇듯 기능적으로는 이점이 두드러지기보단 관리 방식의 차이가 발생한다. 중앙 관리해서 좋은 점은? 1. state가 너무 늘어나서 헷갈리는걸 방지한다. state가 열 몇 개씩 쌓이면 이게 어떤 state인지 헷갈리기 시작하는데 이를 방지할 수 있다. 2. 다른 state의 이전 값을 참조해서 최신 값을 만드는 ..

기존 useState를 쓸 때 발생하는 문제 아래는 리액트로 양방향 입력 컴포넌트를 만드는 흔한 예시이다. 양방향이란, 1. 유저가 input 태그에 입력해서 state값을 바꿀 수 있고, 2. 시스템이 다른 handler함수에서 setState를 통해 렌더된 인풋을 바꿀 수 있음을 의미한다. const [state, setState] = useState(””) 이게 틀리다는 건 아닌데 이런 식으로 하면 state가 바뀔 때마다 input이 재렌더 된다. value={state}때문에 state값의 변화에 영향을 받는 이 input컴포넌트는 엄청나게 많은 재렌더 api를 쏘게 되는데.. (단순 키보드 입력 때마다 state가 바뀌기 때문. state가 쓰이는 모든 곳이 재렌더 된다.) 성능적으로 민감한 ..

리액트 포털은 언제 쓰는가? 웹페이지를 만들다보면 종종 모달을 만들 상황이 발생한다. 많은 사람들이 모달을 그때그때 모달이 필요한 페이지의 자식으로 만들고 있다. 그렇게 되면 원래라면 해당 페이지의 맨 아래 있어야하는 모달을 css를 사용하여 최상단에 있는 것처럼 꾸미는 것이다. 이게 완전히 틀리다는건 아니지만, 의미적으로 좋지 않긴 하다.(최상단에 보이는 컴포넌트가 사실 맨 아래에 있는건데 z-index만 조작해서 위에 있는것처럼 보임) 의미적인 측면 뿐만 아니라 기능적으로도, 모달을 발생시켜야 하는 지점이 매우 깊은 곳이면, 그 상위요소들의 css에 모두 영향을 받는다. z-index가 다른 의존성 때문에 잘 안 올라가는 경우도 생길 수 있음. (리액트 루트를 넘어) 최상단으로 모달같은 컴포넌트를 보..

JSX코드가 처리되는 과정 JSX는 자바스크립트 코드가 HTML처럼 보이게 만든 일종의 Syntax Sugar일뿐이다. 실제로는 자바스크립트이다. // JSX return Let's get started! // 원시 React? return React.createElement("div", {}, React.createElement("h2", {}, "let's get started"), React.createElement(Expenses, {item: expenses}) ) //최상위 div에는 속성이 없으므로 빈객체{}를 2번째 인자로 제공한다. 위 예시의 아래 부분처럼 실제로 JSX 문법이 나오기 전까진 createElement() 메소드의 체이닝을 계속 했어야 했다. (return문은 단 하나의 값..

메모이제이션 연산의 결괏값을 메모리에 저장해 두고 이전 값과 결과가 동일할 때 재사용하는 기법 그렇다면 react의 메소드들은 어떤식으로 메모이제이션을 하고 있을까? React.memo()는 props의 값으로 변경을 확인을하고 useCallback()과 useMemo()는 dependency 배열 내부의 값으로 변경사항을 확인한다. React.memo() - 컴포넌트 자체를 메모이제이션 - 자체적으로 props값을 비교해서 달라진 부분이 없다면 리액트 DOM에서 비교 작업이 들어가지 않는다. useCallback() - 함수 자체를 메모이제이션 - 자바스크립트에서 함수는 객체로 취급되기 때문에 리렌더링이 일어날 때마다 새로운 함수가 생성 - 자식 컴포넌트의 불필요한 리렌더링을 막기 위해선 useCall..

리액트에서 동적으로 컴포넌트를 추가해주고 싶을 때 map 메소드를 주로 사용한다. 그런데 map 메소드가 순회할 때 JSX코드를 뱉어낼 때 key인자가 없다면 리액트가 개발자 도구에 경고 메시지를 출력한다. 그런데 왜 key props가 필요한지를 알아보자 이유: 렌더링 최적화 Key는 React가 어떤 항목을 변경, 추가 또는 삭제할지 식별하는 것을 돕는다. 만약 Key가 없다면 배열에서 무언가 수정하거나 삭제하면 전체 배열을 다시 렌더링하게 된다. 그러나 Key를 넣어준다면 해당 instance만 수정하거나 삭제하여 불필요한 재렌더를 방지할 수 있다. 주의할 점: map((value, idx) => { return }) 처럼 2번째 인자를 key에 넣는 것도 좋지 않다. 에러를 없애기 위해 임시 방편..

Props를 자손으로 쭉쭉 내려다보내다보면 props가 어디까지 보내지는지 그 깊이를 알기 어려워지는 현상. 3~4개면 어떻게든 파악을 할텐데, depth가 15개 이상이면? props가 어떻게 보내지고 있는지 파악하는 것 자체가 시간이 든다. import React from "react"; import "./styles.css"; export default function App() { return ( ); } function FirstComponent({ content }) { return ( I am the first component; | ); } function SecondComponent({ content }) { return ( I am the second component; ); } fun..

클래스형 컴포넌트 import { Component } from 'react'; export default class MyComponent extends Component { constructor(props) { super(props); this.handleClick = this.handleClick.bind(this); this.state = { count: 0, }; } handleClick() { this.setState({ count: this.state.count + 1 }); } render() { const { count } = this.state; return ( {count} 클릭해보세요! ); } } react 라이브러리에서 제공하는 Component를 import 받아와서 상속 관계를..