비온 뒤 무지개 발견😲 n년 만에 본 것 같다.
Flux Architeture (flux pattern) : 확장 어플리케이션의 상태 관리를 처리하는 패턴. Action, Dispatcher, Store, view의 네가지 필수 구성요소를 가짐
- Facebook에서 클라이언트-사이드 웹 어플리케이션을 만들기 위해 사용 (zombie chat tap bug, fragile structure issue, building SPAs?..아마도 2014 즈음 or 그 전 부터)
- react의 등장으로 mvc등 또는 아예 스파게티 코드 등에서 항상 겪어오던 구조상의 문제를 약간은 해결해주는 듯 싶었으나, 규모가 커지니 역시 상태관리가 복잡해짐(state lifting up, props drilling) -> flux pattern으로 해결 (view-action/dispatch-reducer/store-view의루프. 즉, 단방향 데이터 흐름을 유지함으로써)
Redux: (아하! Reduxnaming Reducer and Flux)
flux 패턴의 대표 라이브러리가됨 (다른 예로 mobxm, recoil등 있지만, redux사용 압도적-npmtrends.com), redux를 리액트의 하위 라이브러리로 알고 있는 경우도 있는데, 리액트 사용하지 않고도 쓸수 있다. 상태 관련 라이브러리
"Action객체가 Dispatch메소드에 인자로 전달되고, Dispatch는 Reducer를 호출해서 store에 new State를 생성"
{...prevState, name:actioin.name}
Object.assign({},state,{바꿀부분})
스프린트 이전 혼자 학습할때나, 스프린트 진행 중에 들었던 각종 의문들이 스프린트를 해결하면서, 또 리뷰 시간을 통해서 9할은 해결되었다. 이건 뭐지? 음 이런건가? 하고 내 나름대로 답을 낸것들, 체크해둔 부분이 하나하나 언급되고 해결되니 시-원-
디테일하게 보자면 새롭게 알아둘 개념, 용어들이 참 많았다.
재밌다, 내 힘으로 해결한 것에 대한 뿌듯함
그럼에도 또 튀어나오는 미처 체크하지 못한 디테일이나 새로운 개념-이 스트레스가 아닌 재미로 느껴지는 건, 뭔가 큰 틀을 그려보고 이해해서 그런걸까. 리액트를 처음배울 때보다는 이미 이해한 개념 위에 덧씌우는 부분이라 그런듯하다.
아주 원시적인 내 더티코드를 레퍼런스처럼 리팩토링하기-고민중이지만 좀처럼 맘에 들지 않아 미완
섹션1에서 처음 변수, 반복문 배울때처럼, 모처럼만에 두근두근 재밌다, 그동안 너무 부담감,불안,초조 모드였는데, 오히려 ha가 코앞에 닥쳐서 아예 마음을 비워서 그러나?! 업다운의 반복 (후기공유회의 송이님 나눔처럼, '어려움/멘붕-울적,우울,자괴감-해결,신나'의 무한루프 격공)
혼자만 캠키기가 점점 더 부담스럽다ㅠ, 차치하고 질문좀 제발 전체로 해줬으면..ㅠ 다른이의 질문을 통해 배우는 것이 일상화 된것 같고, 코드스테이츠에서 얻는 귀한 경험 중 하나인 것은 분명하다
좋지 않은 것들은 알아서 쉽게 전염되고 퍼지는데, 좋은 것들을 지켜나가려는 것은 언제나 반작용하는 힘이 있다-물리법칙마냥 이 세상의 법칙인가, 대체 왜 아름답고 선한 힘은 쉬이 이뤄지는 것이 없는 걸까? 쉽게 얻으면 아름답지 못하게 느끼려나, 인간본성인가. 그냥 나인가.