개발자의 삶

https://github.com/wlgys8/Sprites-Outline

상태(state)란?

상태는 변하는 데이터입니다. 특별히 UI, 프론트엔드 개발에서는 "동적으로 표현되는 데이터"입니다.

로컬 상태란?

다른 컴포넌트와 데이터를 공유하지 않는 폼(form) 데이터는 대부분 로컬 상태

input box, select box 등과 같이 입력값을 받는 경우가 이에 해당

전역 상태란?

다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태

서로 다른 컴포넌트가 사용하는 상태의 종류가 다르면, 꼭 전역 상태일 필요는 없다.

출처(source)가 달라도 된다.

그러나, 서로 다른 컴포넌트가 동일한 상태를 다룬다면, 이 출처는 오직 한 곳이어야 한다.

만일 사본이 있을 경우, 두 데이터는 서로 동기화(sync)하는 과정이 필요한데, 이는 문제를 어렵게 만든다.

그렇다면 전역으로 상태를 관리해야 하는 경우는?

ex) 홈페이지 다크모드, 국제화 설정(홈페이지 영어 -> 한글로 번역 )

Side Effect란?

"함수의 입력 외에도 함수의 결과에 영향을 미치는 요인"입니다. 대표적으로 네트워크 요청, API 호출이 Side Effect"

하지만 상태 관리 툴이 반드시 필요하지는 않다.

상태 관리 툴이 없어도 충분히 규모 있는 애플리케이션을 만들 수 있다.

그러므로 장단점을 인지하고 사용해야 한다.

위 컴포넌트의 state를 props를 통해 전달하고자 하는 컴포넌트로 전달하기 위해 그 사이는 props를 전달하는 용도로만 쓰이는 컴포넌트들을 거치면서 데이터를 전달하는 현상을 의미한다.

위 그림처럼 컴포넌트 A의 state를 컴포넌트 D로 전달하기 위해선 사이에 있는 컴포넌트 B, C를 거쳐야 한다.

<Props Drilling의 문제점>

Props의 전달 횟수가 5회 이내로 많지 않다면 Props Drilling 은 큰 문제가 되지 않지만,

규모가 커지고 구조가 복잡해지면서 Props의 전달 과정이 늘어난다면 아래와 같은 문제가 발생한다.

● 코드의 가독성이 매우 나빠지게 됩니다.

● 코드의 유지보수 또한 힘들어지게 됩니다.

● state 변경 시 Props 전달 과정에서 불필요하게 관여된 컴포넌트들 또한 리렌더링이 발생.

따라서, 웹성능에 악영향을 줄 수 있다.

이러한 상황에 다양한 상태관리 라이브러리(Redux, Context api, Mobx, Recoil)를 사용하여 방지할 수 있다.

Redux

Redux에서는 컴포넌트와 상태를 분리하는 패턴을 배운다.

따라서 상태 변경 로직을 컴포넌트로부터 분리하여 표현에 집중한, 보다 단순한 함수 컴포넌트로 만들 수 있다.

기존에 배운 React의 데이터 흐름에 따르면, 최상위 컴포넌트에 위치시키는 것이 적절하다.

하지만 이런 상태 배치는 다음과 같은 이유로 다소 비효율적이라고 느껴질 수 있다.

1. 해당 상태를 직접 사용하지 않는 최상위 컴포넌트, 컴포넌트1, 컴포넌트2도 상태 데이터를 가짐

2. 상태 끌어올리기, Props 내려주기를 여러 번 거쳐야 함

3. 애플리케이션이 복잡해질수록 데이터 흐름도 복잡해짐

4. 컴포넌트 구조가 바뀐다면, 지금의 데이터 흐름을 완전히 바꿔야 할 수도 있음

라이브러리인 Redux는, 전역 상태를 관리할 수 있는 저장소인 Store를 제공함으로써 이 문제들을 해결

1. 상태가 변경되어야 하는 이벤트가 발생하면, 변경될 상태에 대한 정보가 담긴 Action 객체가 생성
2. 이 Action 객체는 Dispatch 함수의 인자로 전달.
3. Dispatch 함수는 Action 객체를 Reducer 함수로 전달
4. Reducer 함수는 Action 객체의 값을 확인하고, 그 값에 따라 전역 상태 저장소 Store의 상태를 변경
5. 상태가 변경되면, React는 화면을 다시 렌더링

   즉, Redux에서는 Action → Dispatch → Reducer → Store 순서로 데이터가 단방향으로 흐르게 된다.

+ https://facebookarchive.github.io/flux/docs/in-depth-overview/

현재 본인은 데스크탑과 랩탑이 모두 있으나 사용하기 편한 데스크탑을 주로 사용중이다.

앞으로 개발을 하는데 있어서 mac을 사용하면 유지보수나 개발에 편리하다고 들어서 고민을 하다

우선 학원의 lental service를 신청하고 기다리고 있었다.

오늘 한 것은  우분투 설치 및 CLI를 배우고 nvm과 npm에 대해 기초적으로 배웠다.

window와 mac은 각각 설치 방법이 달라 mac을 받게 된다면 다시 설치방법을 보고 공부해야 할 것이다.

CLI(Command-Line Interface) 명령어

pwd : 현재 위치 확인하기

mkdir : 새로운 폴더 생성하기

ls : 특정 폴더에 포함된 파일이나 폴더 확인하기

explorer.exe . : WSL에서 현재 위치를 GUI로 실행하기

cd: 폴더에 진입하기

touch: 파일 생성하기

rm: 폴더나 파일 삭제하기 (파일을 지우려면 뒤에 -rf를 추가적으로 붙인다.)

mv: 폴더나 파일의 이름을 변경, 또는 폴더나 파일의 위치 옮기기

cp: 폴더나 파일을 복사하기

Git 환경설정

사용자정보

$ git config --global user.name "나의 사용자 이름"
$ git config --global user.email "내 이메일 주소"

이 명령어들을 우분투나 VsCode같은 곳에 입력하면 된다.

SSH 키 생성

ssh-keygen

ssh-keygen 명령어는 경로 ~/.ssh./ 에 두 파일 id_rsa와 id_rsa.pub를 생성

이 두 파일은 ssh 키 페어라고 하며, 이 중 id_rsa.pub는 누구에게나 공개해도 되는 공개키(Public Key)라고 한다.

그리고 id_rsa는 공개되면 안 되고 나만 보관하고 있어야 하는 키라고 하여

개인키(Private Key) 또는 비밀키(Secret Key)라고 한다.

SSH 키 페어를 생성하였으므로, 생성된 키 페어 중 공개키를 복사하여 gitub에 등록

cat ~/.ssh/id_rsa.pub

1. Github로 이동하여 로그인

2. 우측 상단의 프로필 이미지 클릭 후 Settings에 진

3. 왼쪽의 내비게이션에서 SSH and GPG keys를 선택

4. 나타난 화면에서 SSH Keys 옆의 초록색 버튼 New SSH Key를 클릭

5. 등록한 SSH 공개키를 구분할 수 있도록 사용자 임의로 Title을 작성,

Key에는 복사해 둔 공개키를 붙여 넣고, Add SSH Key 버튼을 클릭

6. Confirm access에서 Github 로그인에 필요한 비밀번호를 입력해 SSH key 등록을 승인