일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- deep
- 프로그래머스
- 백준
- BOJ
- programmers
- 상태
- memory
- Java
- 원리
- Dive
- EventListener
- Hook
- react
- API
- DoM
- 프로젝트
- 상태 끌어올리기
- LeetCode
- State
- 유용한 사이트
- 꿀팁
- 가상 DOM
- 요청
- axios
- virtual Dom
- javascript
- 개발
- Today
- Total
목록전체 보기 (29)
탄탄한 기본기!

한 번쯤 들어보고, 이용해 보았을만한 알아두면 좋을만한 사이트들 정리 1. bestofjs https://bestofjs.org/ Best of JavaScript Check out the most popular open-source projects and the latest trends about the web platform and Node.js. bestofjs.org 장점 태그 별로 원하는 카테고리의 프로젝트들을 모아볼 수 있음 Monthly Rankings, Recently Added Projects 등 모아볼 수 있음 순서대로 정렬할 수 있다. 어제/7일 내에/12월 내에 github stars를 많이 받은 순서 한 달 동안 다운로드 수 등 보기 깔끔함 단점 아직 못찾음 2. Css Scrip..

Karma + Jasmine 환경 설정 Karma는 실제 브라우저에서 테스트를 진행할 수 있도록 해주는 Test-Runner이며, Jasmine은 Karma와 같은 Test Runner 환경에서 돌아가는 행동 기반의 자바스크립트 테스팅 프레임워크이다. 먼저 Karma와 Karma에서 돌아갈 Jasmine 의존성을 설치한다. npm i -D karma karma-jasmine karma-safari-launcher 그다음 karma 설정 파일을 생성해준다. 공식문서에 따르면, 따로 arg를 주지 않는 이상 ./karma.conf.js ./karma.conf.coffee ./karma.conf.ts ./.config/karma.conf.js ./.config/karma.conf.coffee ./.config..

Client Side Routing (React Router 등)을 사용한 React 앱을 배포했을 때, index.html(root)에서 HTML5 pushState history API 를 활용해서 앱이 잘 동작하지만 만약 /www.example.com/user 등의 root가 아닌 경로에서 새로고침을 하거나, 직접 해당 경로를 요청하면 404 page not found 에러를 만나게 되었다. 분명 webpack의 dev server에서는 잘 동작했는데 도커 컨테이너로 테스트해보니 라우팅 과정에서 에러가 발생하는 것 같았다. 로컬에서 dev server로 라우팅을 할 때에는 라우팅 경로에서 새로고침을 하거나, /subject/ko 등으로 직접 접근해도 정상적으로 동작하는 반면에, productio..

웹 개발을 하던 도중, 배경화면으로 사진들을 렌더링하고 그 위에 다른 HTML 요소를 렌더링 하고자 했다가 아래와 같은 상황이 발생하는 이슈가 있었다. 해당 이슈의 원인은, background 이미지로 사용되는 이미지가 load 되지 않았을 경우에 이를 포함하고 있는 컨테이너의 height가 auto이기 때문에 height가 0으로 취급되기 때문이었다. 그래서 고민하다가 이미지가 load 되었는지 상태를 감지해주면서 이미지가 load 되었을 때만 컨테이너 내부의 요소(컴포넌트) 들을 렌더링 하도록 로직을 작성해보았다. import React, { useState } from "react"; import { styled } from "linaria/react"; interface IProps { src: ..

0. 개요 DOM 요소에 이벤트를 바인딩해주고 이를 해제해주는 과정에서, 문득 이벤트 리스너들이(메모리가) 잘 해제되는지 궁금해 개발자 도구를 열어 performance 탭의 memory 부분에 있는 리스너 개수를 확인해보았다. 그런데 removeEventListener를 호출할 때, 리스너 개수가 줄어드는 것이 아닌 오히려 증가했다가, 나중에 GC에 의해 리스너가 사라지는 것을 확인하고 이 부분을 조금 더 확인해보며 그 내용을 정리했다. 1. HTMLElement.prototype.removeEventListener 개념 보통 DOM요소에 이벤트 핸들러를 바인딩해서 다양한 이벤트를 캐치한다. 하지만 메모리 누수 방지를 위해서 불필요할 경우 (컴포넌트가 unMount 되는 등) 이를 해제해주어야 한다. ..

React 내부 동작 원리를 알아야 하는 이유 React는 아주 많이 추상화되어 있는데, 일반적으로 React를 공부하는 개발자라면 React가 내부적으로 VirtualDOM을 사용하고 있다는 사실을 다들 알 것이다. (모른다면...? Virtual DOM and Internals) 그리고 React가 16.8 버전업이 되며 hook이라는 개념이 등장한 후 많은 (거의 대부분...) 개발자들이 이 hook에 대해서 공부하고, 사용하고 있다 (참고). 그 이유는 hook이 아주 편리하고, 사용하기 간편하며 심지어 가독성까지 좋기 때문인데 라이브러리가 깊게 추상화가 되어있어서 그런 것이라고 생각한다. 이렇게 사용하기 쉬움에도 불구하고, 내부 동작 원리를 정확하게 이해하지 못하고 사용할 경우 예상치 못한 에러..

Axios 요청 횟수를 줄이자 React로 비동기 통신을 기능을 구현할 때 불필요한 요청을 줄이는 것은 서버 측과 클라이언트 측 모두 성능 개선에 큰 도움이 된다. 예를 들어서, 유저가 텍스트 타입의 Input box에 입력한 단어로 어떠한 결과를 입력할 때마다 바로바로 검색하는 API에 GET 요청을 한다고 가정하자. 그럼 Input tag의 onChange props로 매번 타이핑을 할 때마다 API요청을 보낼 수 있을 것이다. 하지만 Apple pie라는 단어를 검색할 때 A Ap App Appl ... Apple pi Apple pie 모든 경우에 대해서 모두 API 요청을 날릴 것이다. 음... 일단 기능은 되니까 됐다(?)라는 생각이 든다면 몰라도 나의 성격 상 절대 그럴 수 없다. 여러 가지..

1. 프로젝트 진행 동기 나는 평소에 공부할 때, 공부한 내용들을 진짜 내 것으로 만들었는지 확인하기 위해서 직접 코드로 짜보며 궁금했던 것들을 직접 확인하는 습관이 있다. 그래서 최근 리액트를 공부하면서 배운 내용들이 진짜 내 지식이 되었는지, 스스로 코드를 짤 수 있는지 확인하고 싶어서 간단한 프로젝트 하나를 만들어보며 더 많이 공부해보기로 결심했다. 그래서 Git 버전 관리, React 개발 환경 (webpack, babel 등) 세팅 및 컴포넌트 상태 관리, 스타일링 방법 등에 중점을 두고 아래와 같이 동작하는 아주 간단한 애플리케이션 하나를 제작해보았다. 이번 프로젝트에서는 관리해줄 상태가 매우 적었기 때문에 Redux와 같은 상태 관리 라이브러리는 사용하지 않았고, React의 Context ..