record4me

-세번째 프로젝트를 마치며, 휴먼에러로 삽질만 몇 번을 했는 지 모를 2일을 보내고 다른 2일간은 prop-drilling, 1일은 redux로 개선하는 시간을 보냈어. 첫번째 삽질만 아니었어도...하지만 의미있는 삽질이었어. ㅎㅎ prop-drilling-context-redux 처음 prop-drilling할 때 휴먼에러로 고생한 것과 초기 state 데이터 형태가 배열과 객체로 따로 관리되서 setState로 변한 값을 설정해줄 때 데이터 형태를 어떻게 뿌려줄 지 무지 고민했던 것 같아. contextAPI를 사용해서 state를 공유하니까 정말 세상 편하지 않을 수가 없더라. prop-drilling에서 답답했던가 1차로 싸악 풀렸어. 하지만 최상위 컴포넌트에서 state를 보내주려고 하니까 왔다..

Ducks Pattern 리덕스를 사용하기 위해선 리덕스의 구성요소들을 모두 만들어야 사용이 가능해. 이건 개발자 마다 다를 수 있어. 그래서 협업하면 중구난방일 경우가 상당히 높은데 Erik Rasmussn 라는 분이 통일시키기 위해 패턴화를 시켜줬어. 그게 ducks pattern이야. 덕스 패턴은 이미 쓰고 있어. 이전에 했던 모듈 파일 1개에 Action Type, Action Creator, Reducer가 모두 존재하는 작성방식이야. Reducer 함수를 `export default` 해. Action creator 함수들을 export 하고 Action type은 app/reducer/ACTION_TYPE 형태로 작성해. // counter.js // action value const PLU..

useState와 useRef를 사용하는 input 내부의 값 관리 useState로 하면 많은 값을 같이 불변성을 지키면서 눈으로 즉각 보며 관리를 할 수 있어서 좋고 useRef는 그 부분의 값을 저장하고 해당 부분을 콕 짚어서 제어할 수 있어서 좋아서 같이 필요한 곳에 쓰믄 좋은 것 같아. input값의 변화를 ref로 다룬다면 이렇게 가독성은 떨어지는 것 같아. const test = () => { const inputOneRef=useRef(Number) const inputTwoRef=useRef(function(){}) const inpuThreetRef=useRef(String) const inputfiveRef=useRef(boolean) const inputfiveRef=useRef()..

Redux -Action Value Creator 중앙 데이터 관리소인 store에서 리듀서는 store에 들어있는 state(상태)를 제어해. 들어온 state값으로 지지고 볶아서 내보내주거나 보관하는겨. 초기 리듀서는 이렇게 고지식했어. // counter.js // 초기 상태값(state) const initialState = { number: 0, }; //원래라면 // const [number, setNumber] = useState(0); 지만 위처럼 바꾼거야. // 리듀서 : "state에 변화를 일으키는"함수 // (1) state를 action의 type에 따라 변경하는 함수 // state를 action 안에 있는 type에 따라서 변경하는 작업 // input : state, acti..

useDispatch -state를 바꾸는 방법 중에 하나야. -action객체를 이용해서 action의 type에 따라서 바꿔줘. 위 그림을 펼쳐보자면, 중앙 데이터(state) 관리소인 store 안에는 1. state도 있고, 2.리듀서(Reducer)도 있어. state는 상태(상태 값)이고, 리듀서는 state(상태)를 제어해줘. 돌아가는 원리 1. 현재 보여주는 UI는 => App.jsx 컴포넌트라고 할 때, ui에서 이벤트가 일어나서 2. 중앙 데이터 관리소인 store에 있는 state => counter의 값을 바꿔야한다는 요청을 UI(컴포넌트)에서 하면 예를 들어 이런 요청 => ex) onClick={setState(counter + 1)} 3. 그 요청을 Dispatch란 애가 수행..

리덕스를 세팅하면서 useSelector로 state값이 잘 들어오나 확인하려고 state전체를 가져와서 통째로 리턴했더니 불필요한 렌더링이 일어났다며 전체 state를 반환하는 Selector는 상태가 변경될 때마다 다시 렌더링되니까 주의하라는 메세지가 떴어. 발생한 경고 Selector unknown returned the root state when called. This can lead to unnecessary rerenders. Selectors that return the entire state are almost certainly a mistake, as they will cause a rerender whenever *anything* in state changes. 원인 코드 impor..

useContext -react context의 필요성 부모=> 자식 컴포넌트로 데이터 전달할 때 props로 전달했어. 부모 => 자식 => 그 자식 => 그자식의 자식 => prop driling 이런 위에서 아래로 props를 보내는 props drilling => 깊이가 너무 깊어지면 부모에서 자식으로 넘겨줄 때 여러개의 컴포넌트있을 경우 어디에서 prop이 왔는 지 알수 없기도하고 오류가 무조건 생기며 원인 파악 힘들어 하지만 context API를 쓰면 전역으로 데이터를 관리할 수 있어 어떤 컴포넌트든 전역적으로 선언되어있는 데이터에 접근 가능해. contextAPI 필수 개념 createContext : context 생성 (컨텍스트를 만드는) Consumer : context 변화 감지 (..

리액트에서의 map 사용 리액트에선 배열을 받아서 순서있는 엘리먼트 리스트를 출력하는 컴포넌트를 쓸 때 key값을 부여해. -key는 React가 어떤 항목을 변경, 추가, 삭제할 때 식별하는 걸 도와. 엘리먼트에 안정적인 고유성을 부여하기 위해서 배열 내부에 있는 요소에 key속성을 주고 값을 지정해줘야 해. 예를 들면, const ElementKey = () => { const array = [ { id: 1, name : 보라돌이, }, { id : 2, name : 두비, }, { id : 3, name : 나나, }, { id : 4, name : 보, } ] return ( {array.map((data) => { const { id, name } = data return( {name} ) }..

두번째 개인 프로젝트 피드백 반영 App.js는 리액트 컴포넌트니 다른 뷰와의 통일성을 위해 확장자를 jsx로 변경 App.jsx 유무 처리 불필요한 빈 태그 처리 주의!! uuid, shortid등을 사용 TodoForm에서 todoInputs => setTodoInputs의 함수형 업데이트를 이용 유사한 형태의 UI를 공통화-> 템플릿 여기서 템플릿은 총 3번을 걸쳐 다시 만들어졌는데 첫번째는 -첫번째 템플릿 import React from "react"; import TodoCards from "view/main/todoCards/TodoCards"; // 템플릿 만들기 export const StateTemp = ({ title, isDoneState, todoInputs, setTodoInput..