유저가 fire버튼을 누른다->onClick에 묶인 store.dispatch 함수가 작동한다->dispatch 함수는 인자인 고유한 액션을 reducer함수에 전달한다->reducer함수는 action.type을 읽고 다음 스테이트의 color값에 action.color을 넣는다->dispatch함수 작동시 store.subscribe함수가 작동하면서 인자인 red/blue/green 렌더함수를 작동시킨다->렌더 함수 내 state.color는 reducer가 반환한 새로운 스테이트를 따른다->모든 컴포넌트의 background-color가 state.color값에 따라 변한다. 이때 각 컴포넌트는 서로에 대해 모르고 연관되어 있지도 않다.
without-redux: 부품들이 서로 의존하고 있어서 한 부품이 바뀌면 다른 부품까지 다 코드를 수정해줘야 하고, 부품 하나를 만들 때도 다른 부품에 미칠 영향까지 생각해야 함.
with-redux: 부품이 서로의 존재를 1도 모름. 그래도 잘 돌아간다. 각 부품은 자기의 일에만 집중하면 됨. 한 부품이 바뀌어도 다른 부품까지 수정할 필요가 없다. 그래서 개발자 입장에서 훨씬 편하다. 개발자는 각 부품이 제 역할을 잘 하도록 하는 데만 집중하면 된다.
원래 서로의 컴포넌트들은 자신의 상태가 변경되었을때, 자신에게 의존하고 있는 다른 컴포넌트들에게 그것을 직접 알려줘야 했다. 하지만 redux를 사용하게 되면 모든 컴포넌트들이 랜더링 될때 필요한 데이터를 담고 있는 state를 만들고, 만약 action을 전달하여 reducer를 통해 state가 변경되게 되면 모든 컴포넌트들에게 state가 변경되었음을 알리고 state가 변경됨에 따라 subsctibe에 포함되어있는 함수들이 실행되면서 컴포넌트들이 재랜더링되기 때문에 컴포넌트들간의 의존성이 낮아지고 컴포넌트들은 각자 자신의 상태에만 집중할 수 있게 된다.
지금 이해한 상태에서 Redux를 쓰면 state의 과거, 현재 흐름을 알 수있음.
state를 가져오기, 쓰기의 역할이 각자 정해짐으로 인해서 오는 스타일 정립?
state변화를 알려주기때문에 그 사이에 다른 작업을 할 수 있을꺼같음.(이건 예상이긴 한데 state변화 전이나 후에 뭔가 다른걸 해줄 수 있지 않을까 싶어서요.)
관리는 Redux가 해주므로 다른건 신경 안쓰고 작업할 수있음(컴포넌트 작업에 용이, 정해진 방법대로 state를 관리하면 다른 component를 신경쓸 필요없음) 정도 인거 같습니다.
상태관리는 왜하는 것인지 Redux는 왜 쓰는 것인지 react와 같이 공부하면서 봤을때는 귀찮은 일이 더 많아 진다고
생각했는데 강의를 들으면서 정리가 되어서 너무 좋습니다.
아직 좀 더 써봐야겠지만 그림으로 그려주신 게 너무 좋아서 다시 프로젝트할 때도 많이 참고할거같습니다, 감사합니다.