프론트 고수들아 질문좀 하자

[익명(115.188)]

리액트로 폼 작성하고있는데
인풋이 10개가 넘어가고 select도 섞여있는 좀 복잡한거야.
인풋도 텍스트도 있고 라디오버튼도 있고 넘버도 있음.

이걸 스테이트 수 줄이자고 커스텀훅스를 만들어서

그 안에서 검증, 오류, 전송까지 다 처리하려니
예외처리할게 너무 많아서 오히려 코드가 더 번잡해지는거 같음.

이럴때는 그냥 인풋 하나하나 따로 useState로 상태관리하는게 더 나으려나?

보통 복잡한 폼 작성할때 어떤식으로 해?

[익명(218.152)]

MVVM + DI + @

[익명(115.188)]

처음에 DI로 구현하다가 오버헤드인거 같아서 갈아탄거거든. 결국 DI로 해야하나 ㅠㅠ

[익명(180.71)]

DI는 이 문제와 상관이 없어. 너가 가지고 있는 문제는 상태를 어떠헥 관리할것인가에 대한 문제이지, 정책 결정을 런타임에 하는게 필요한게 아니잖아

[익명(180.71)]

각각 관리해야하는 모듈들을 injection해서 코드를 분리하는 방법이 도움될 수 있지만, 결국에는 각 코드끼리 연관되어있다는 점을 생각해야해. 각 모듈끼리의 어댑터 만드는것도 꽤 큰 일일거야.

[익명(115.188)]

예전에는 무조건 가능한데까지 디커플을 하는걸 선호했었는데 최근들어서 그방식이 너무 정황하게 느껴지는거같아. 지금 만드는것 플젝 프론트도 인젝션 한 모듈들도 있긴 한데, 타당한 이유가 없으면 지양하려고 노력중이야 나는 자바에서 많이배운것도 사실인데, 좀 나쁜습관이 든것도 있는거같아

[익명(180.71)]

서버단에서는 디커플한게 쉽긴 해. 의존성이라는게 단순하거든. 프론트에서는 디커플하게 하는 패턴을 그렇게 선호하진 않아... (물론 레거시 서비스에서는 그런형태가 있긴 함 angular같은거) 프론트에서는 의존성이 여러개야 (HTML, 로직, CSS, React관련 로직). 그게 다 연관관계가 있고. 그래서 그런 의존성을 쉽게 분리했다가 오히려 코드가 복잡해지는 경우가 많아.

[익명(180.71)]

예전에 대표적인 케이스로 VAC패턴이라는걸 네이버측에서 발표한적이 있음. 단순하게 UI쪽은 UI만 사용하고 로직쪽은 따로 레이어를 둬서 props로 넘겨주자는거지. 그러면 뷰와 뷰로직이 분리된다는 믿음이야. 근데 실제 사용했던 사례를 보고 단점을 보면 그렇게 단순하게 분리한 케이스가 어떤 단점을 가져오는지 볼 수 있음.

[익명(115.188)]

궁금한게 있는데, 의존성을 분리하지 않고 테스트코드를 쉽게 짜는 방법이 어떤게있을까? 일단은 비지니스로직들은 의존성을 다 분리를 하는편이거든. 유닛테스트를 위해서.

[익명(180.71)]

ㅇㅇ 그렇게 해도 됨. 모듈화를 시켜서 props로 주입시켜 실행하는것도 방법이고 보통 Component는 행동 테스트를 해. Component내부에 쓰이는 state같은건 다 내부구현이라 생각하는거고.. 그래서 그냥 컴포넌트가 랜더링 된 결과가 이전과 같은지 볼 수 있어.

[익명(180.71)]

https://kentcdodds.com/blog/testing-implementation-details

[익명(115.188)]

VAC 패턴 발표영상도 봐야겠다. 언뜻 봐서는 내가 하는 스타일이 좀더 고도화된거같은데, 혹시 니가 언급한 실제 사용했던 사례와 단점을 어디서 찾을수있을까?

[익명(180.71)]

VAC패턴의 영상에 쓰면서 불편했던 점들이 나와있어 ㅋㅋ VAC발표영상봐봐

[익명(115.188)]

아 고마워. 며칠동안 잠못잤던 고민들이 풀리거나 실마리가 보인다. 아직 취준이라 실무가 어떻게 돌아가는지 잘 몰라 ㅠㅠ

[익명(180.71)]

https://www.youtube.com/watch?v=HYgKBvLr49c
이
영상 보면 의존성을 굳이 분리하는것이 아니라, 의존성을 드러내는 방식에 대한 방법도 나와있어
물론 너가 쓰는 방식인 모듈을 분리하고, props로 주입하는것도 자주 쓰는 방식이야 (대신 이런 경우, 좀 공통모듈이거나, 유닛테스트가 필요한 중요한 비즈니스로직의 경우..)

[익명(180.71)]

모든 모듈들을 props로 주입시키는건 (특히 이 글에 쓰여있는 상태 관리의 입장에서는) 좀 적합하지 않을 수 있지.

[익명(115.188)]

저 상태관리 로직을 처음에 인젝션으로 짜려다 너무 장황한거같아서 좀 시작하다가 접고, 일단 각각 state들을 다 만들어서 구현은 다 한 상태인데, 커스텀 훅스 예제들을 보고 이런식으로 다시 구현을 해볼까 고민중이였거든. 그냥 중복되는 코드들만 좀 제거하는 식으로 리팩토링만 해야겠다.

[익명(115.188)]

깔끔하게 브랜치 폭파 ㅇㅇ

[익명(180.71)]

1. 상황에 따라 달라. 대체적으로 하나의 훅스안에 다 떄려넣는것은 좋지 않을 수 있음. 추상화 레벨을 어디까지 하는게 다른 개발자들이 읽기 좋을것인가 생각해보는게 좋고. 2. 보통 form가 많고 하나의 state가 여러 State에 영향을 주는 경우, fsm을 그려보는것도 추천해.

[익명(180.71)]

fsm이 익숙하지 않다면, 나올 수 있는 UI상태의 케이스를 그려보고, 어떤 이벤트를 받으면 그 UI상태로 옮겨가는지 생각해보는 방식이라고 보면 좋을것같아.

[익명(180.71)]

https://www.youtube.com/watch?v=Hv_PhrfwerQ
이 영상을 참고해

[프갤로(gotopg)]

[프론트공부(112.187)]

오 나두 봐야겟다 .... 우왕 ㄳㄳ!!

[익명(115.188)]

FSM 처음보는건데 신선하다. 뭐 원래 유명한건데 나한테만 신선한거겠지?? 좀 읽어봐야겠다. 꼭 저대로 구현을 안하더라도 힌트를 얻을수있을거같아

[익명(180.71)]

ㅇㅇ 그냥 이건 어떻게 생각을 정리할것인가에 대해서도 힌트를 많이 줘. 기획자 입장에서 나올 수 있는 UI상태를 기준으로 모든 가정사항을 그려보고 연결고리를 그려보는것도 도움되지. 다행히 React에는 useReducer라는 훌륭한 툴이 존재하는거고