일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 알고리즘
- 컴퓨터공학
- github
- 프론트엔드개발자
- js
- 자바스크립트
- 부트캠프
- LinkSnap
- CSS
- Javascript
- 코테
- 코딩테스트
- 호이스팅
- 그리디
- KAKAO
- 컴퓨터과학
- nodejs
- 국비지원
- html/css/js
- cpu
- DFS
- 야놀자
- git
- 국비지원취업
- CS
- 백준
- 패스트캠퍼스
- 너비우선탐색
- computerscience
- BFS
- Today
- Total
목록FrontEnd/React (27)
My Boundary As Much As I Experienced
오늘 만든 resize 이벤트가 끝나면 0.5초 이후 true값을 반환하는 useCatchResizeEnd 훅. import { useEffect, useState } from 'react'; export const useCatchResizeEnded = () => { const [isEnded, setIsEnded] = useState(false); useEffect(() => { let resizeTimeout: NodeJS.Timeout; setIsEnded(false); const handleResize = () => { clearTimeout(resizeTimeout); resizeTimeout = setTimeout(() => { console.log('timeout이 멈췄습니다.'); set..
테스트 라이브러리 구성 React Testing Library 시뮬레이션된 DOM을 제공(Provides Simulated DOM for TEST) 그러나 테스트 러너 없이는 사용할 수 없다(JEST, VITEST) Jest vs Vitest Vitest가 Jest보다 빠르다. Jest는 Vite에서 깔기 힘들다. 테스트의 방식 expect 글로벌 단언 matcher: 어떤 단언인지 jest-dom에 의거함 expect(element.textContent).toBe(”hello”); expect(elementsArray).toHaveLength(7); Jest-DOM 테스트 전에 import되어야 함 matcher를 쓸 수 있게 해줌 toBeVisible, toBeChecked 전역 함수로 test함수가..
프로젝트를 시작하며 (기획, 디자인) 이번 프로젝트는 숙박 예약을 위한 서비스의 전과정을 구현하는 프로젝트였다. 2주라는 짧은 기간동안 전과정을 구현하는 것은 매우 도전적인 과제였고, 멘토님께서 언급한 '기술적으로 단단한 서비스'를 만드는 것을 목표로 진행하였다. 어김없이 내가 초반 이틀 정도는 피그마 디자인을 만들어 제공했는데, 자연스럽게 모바일 - 태블릿 사이즈를 모두 지원하는 느낌보단, 전체적으로 모바일 사이즈를 무리하게 늘려놓은듯한, 요소 하나하나가 비대한 디자인이 되었다는 점은 조금 아쉽다. 내가 개발했던(그리고 지속적으로 관찰했던) 메인페이지 파트의 요소들만 웹 기준으로 적합한 느낌이 든다😅 전 프로젝트(8lack)에선 나름 시간이 남아서 그래픽적인 부분까지 필요하면 신경을 좀 썼더니 팀원들의..
요새 유행하는 번들러 환경 Vite에, 가장 유명한 테스팅 라이브러리 Jest를 엮어쓰려고 했으나 Jest는 웹팩 기반 라이브러리라 Vite환경에서 쓰려면 매우 복잡한 설정들을 거쳐야 한다. 아래 글에서 더욱 자세히 알려준다. vite 에서는 import.meta.env.VITE_XXX 와 같이 환경 변수를 사용하는데 WEBPACK 환경에서 위와 같은 환경 변수를 사용하기 위해서는 별도의 babel 관련 설정이 추가되어야 합니다. https://velog.io/@saeeng/VITE-VITEST-migrate-from-Jest VITE + VITEST (migrate from Jest) Vite > Vite의 사전 번들링 기능은 Esbuild를 사용하고 있습니다. Go로 작성된 Esbuild는 Webpa..
https://dev.to/hannahadora/jest-testing-with-vite-and-react-typescript-4bap Installing Jest for Testing in Your Vite-React TypeScript Project. A Step-by-Step Guide. Introduction Application testing is an important aspect of web development. It helps... dev.to 2. in tsconfig esModuleInterop: true 3. cypress 제외 in tsconfig exclude: []에 추가 4. scss나 styled-component를 사용할 시 우회 proxy를 설정
테스트에는 유닛테스트와 인터그레이션 테스트, 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가 다른 의존성 때문에 잘 안 올라가는 경우도 생길 수 있음. (리액트 루트를 넘어) 최상단으로 모달같은 컴포넌트를 보..