리덕스에서 상태의 변경은 모두 동기적으로 일어납니다. 따라서 미들웨어를 통해 스토어 상태 변경 프로세스 중간에 비동기 로직을 끼워 넣어야만 API 요청에 따른 상태변경을 수행할 수 있습니다. 그러한 미들웨어가 redux-thunk 나 redux-saga 같은 리덕스 생태계 패키지입니다. 리덕스 사가가 제공하는 createSagaMiddleware() 함수를 실행시켜 반환된 객체를 미들웨어로 등록시키고, run 메서드를 실행하면 리덕스에 사가를 적용할 수 있습니다. 리덕스 사가로 할 수 있는 일 리덕스 사가는 단순히 비동기 처리를 위해 만들어진 패키지가 아닙니다. 그건 그냥 미들웨어로도 충분히 가능합니다. 리덕스 사가는 사이드 이펙트를 더 쉽게 관리하고 더 효과적으로 실행하며 더 쉽게 테스트하고 더 나은 ..

리액트는 어떤 과정을 통해 렌더링을 수행하는가? 전통적인 방식 자바스크립트를 이용한 전통적인 렌더링 방식은 단순했습니다.문자열로 HTML 을 생성하고 그 안에 Data 가 들어갈 부분을 지정하는 것이었죠. 이렇게 Data 와 HTML 이 조합된 문자열을 브라우저가 받아내서 렌더링하도록 만드는 것이었습니다. 하지만 이 전통적인 방식의 문제점은 조금의 변경사항을 반영하고 싶어도 브라우저가 전체를 다시 렌더링하도록 만들 수밖에 없다는 점과 실제로 렌더링 결과물이 바뀌지 않았음에도 새로운 데이터를 받았다는 이유만으로 렌더링이 다시 일어나는 비효율이 발생하는 문제가 있었죠. 리액트의 방식 리액트는 이러한 비효율을 줄이기 위해 JSX라는 새로운 파일 형식을 도입했습니다. JSX를 통해 데이터가 들어가야 할 부분을 ..

www.youtube.com/watch?v=vb7fkBeblcw 특성 로컬스토리지는 오직 문자열만을 저장할 수 있지만 Indexed DB 는 객체 자체를 저장할 수 있으며 다른 무거운 파일도 넣을 수 있습니다. 같은 도메인에 접근하면 같은 데이터를 사용하게 됩니다. API 가 '비동기적'입니다. 키-밸류 페어로 동작합니다 사용법 데이터베이스를 엽니다. 데이터베이스 안에 객체 Store를 생성합니다. 성공한다면, Transaction 을 수행합니다. 작업이 끝나면 Transaction 을 끝냅니다.

들어가면서 이 시리즈는 최신 트렌드를 반영하면서, 최대한 현업에 가깝되 간단한 웹 프론트엔드 프로젝트 구성을 목표로 합니다. 이 시리즈는 저 나름의 노하우를 공유하고 피드백을 받고 싶어서 만들었습니다. 어떤 기관이나 업체의 표준을 따르는 것이 아닌 그저 제가 프로젝트를 만들어나가는 과정을 정리했습니다. 하지만 그렇다고 해서 시리즈의 모든 내용들이 처음부터 끝까지 제 머리에서 나온 것은 아닙니다. 특정 부분마다 어느 저자의 어느 글을 참고했는지 그 출처 링크를 표시하도록 하겠습니다. 만들고자 하는 어플리케이션 만들고자 하는 어플리케이션은 간단한 시간관리 앱인 'Micro' 어플리케이션입니다. 제가 친하게 지내는 디자이너분께 사용에 동의를 구했습니다. 이 시리즈에서 이 어플리케이션 전체를 만드는 과정을 다루..

프론트엔드 개발자 활동을 하다보면, 아주 가끔 다른 사람들이 제가 왠만한 디자인은 구현할 줄 알고, 요청 사항대로 거의 모든 부분을 해결해주기 때문에 제가 뛰어난 개발자라고 말해주시는 고마운 분들을 만납니다. 하지만 저는 그런 말을 들을 때마다 마음 한쪽이 불편합니다. 사실은, 저는 '구현'만 할줄 알지 그 내부 원리는 제대로 안다고 말할 수 있는 것이 매우 적기 때문입니다. 물론 당장 개발 하는데 그런 이론들이 직접적으로 도움이 될지는 잘 모릅니다. 주된 코드들이 정해진 프레임워크 양식이나 API들을 따라서 작성되는 프론트엔드 개발의 특성상, 이런 내용들을 안다고 내 코드들이 조금이라도 달라지려나 하는 의구심도 드는 것은 사실입니다. 하지만, 어디가서 제가 '프론트엔드 개발자'라고 당당하게 말할 수 있..

브랜치 종류는 크게 아래와 같다. master develop feature release 실제 개발은 develop 브랜치에서 진행된다. 그리고 develop 자체에서 커밋 내역을 만드는 것이 아니라 feature 브랜치에서 커밋을 만들고 이를 develop 에서 병합하는 식으로 커밋이 이루어진다. 별거 아닌 버그 픽스나 기능 추가는 그냥 develop에서 빠르게 반영한 후 커밋한다. 즉, develop 에서 왠만하면 커밋이 발생하지 않지만 발생할 수 있으므로 feature 브랜치에서 작업을 할 때는 항상 develop 브랜치의 변경 사항을 pull 해와야 한다. 개발이 어느 정도 완료되고 이를 배포하는 시점에서는 Release 라는 이름으로 시작하는 브랜치를 만든다. 해당 릴리즈에서 발생하는 버그나 수..