아 음... 알게모르게 신경쓰고 있던건가 밟아본적이 없네요
# 잡담
h
아 음... 알게모르게 신경쓰고 있던건가 밟아본적이 없네요
h
위 인풋은 폴링객체 참조 가지고 있어서 문제고 아래껀 OK
h
useImmerReducer 스면 잘 되지 않나용 똑같나
h
흠 잠시만요
이거 실험은 안해봤는데
똑같을 것 같은데...
h
codesandbox 요새 너무 자주 터지네요
왜 제가 쓸때만 터지죠
h
리듀서를 쓴다면 dispatch할 때 event객체를 그대로 보낸다기 보단 primitive value를 보내서 발생할 일이 없을 것 같은데
?!
전 좀 느리지만
로드되는데...
혹시 서비스워커 삭제하심이?
h
네 기본적으로 리듀서를 쓰면 문제가 생길일이 없네요
h
아 그래요?
h
와이 낫 리듀서
액션이 두개이상이면 리듀서를 좀 씁시다 하하하ㅏ하하하
h
왜죠ㅕ
지역상태 안복잡하면
쌩짜쓸건데~
h
액션이 두개 이상 == 이미 복잡
상태의 복잡성은 제가 오래 관찰한 결과
field 의 갯수나 중첩 정도로 결정되는게 아니라
바인딩 되는 액션이나 이펙트 수로 결정됩니다
context 가 넓은거 자체는 별 문제가 아니에요
setState 를 남발하면 필드 하나마다 정직하게 액션 하나에 팩토리얼 가짓수의 사이드 이펙트가 나오니 문제지
h
흠?
마지막 말씀 좀더 설명해주실 수 있나요
상관없는 사이드이펙트가 일어나면
안될것같은데
h
아뇨 만든다고 쳤을때요
(그리고 보통 실제로 만듬)
h
흠..? 잘 이해가 안되네요.
h
state 가 아무리 복잡하고 필드개 수백 수천개가 되도 액션을 하나만 바인딩하면 조작법이 한개인건데
필드 갯 수 만큼의 setState 가 생기면요 뭐… 조작방법은 무궁무진해지죠
그렇다고 그 object 통으로 state 에 넣고 mutation 하면 그 액션 가짓수가 줄어든게 아니라 암묵적으로 숨겨버린 것 뿐이니 더 악화되는 것
리액트 API 의 특성 (Hooks 의 deps 반응하는 방식) 덕분에 한번에 그 가짓수가 제한될 수 있는게 그나마 다행인거죠
h
음.. 아마도 제가 여태껏 리듀서 없이 살아온 사람이라 공감을 못하는 것 같은데 좀 더 고민해볼게요.
h
뭐 상태머신 짜세요랑 크게 다른말은 아니였습니다
h
저는 어떤 방식으로든 불가능한 상태만 안나오면 OK
입장이라 useState가 여러개 범벅되어 있어도 최종 리턴이 유한하게 나오면 상관없다라고 생각하거든요
h
그게 기왕이면 증명가능한 방식이면 더 좋지 않을까요
h
증명가능하다는게 리듀서를 통해 좀 더 명시적으로 행동을 제한한다는거죠?
이 맥락에선?
h
원래 예제가 string input 두개였으니까 뭐 맥락이랄게 없긴 하네요 ㅋㅋㅋ
h
아 ㅋㅋ 그러게요
h
이 경우에는 저는 아예 state 를 안씀
h
아 이건 그냥
form-hook으로 충분하죠
h
훅이 왜 필요하죠 킹갓HTML 이 있는데
h
킹갓...
h
스펙확실하고 코드 적고 얼마나 좋습니까…
h
아 ~ validation 귀찮단말이에요~
h
뭘 밸리데이션 하시길래
기본 HTML 로 안되는 수준의 밸리데이션은 이미 파서가 필요하다는 소리라
파서를 짜고 나면 다시 기본 HTML 만 써도 됨
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
h
흠 근데 validation 자체는
그럴수있는데
validation 상태는 필요할 수 있어서요