FE 디자인 설계 관련 고찰

3주 정도로 예상했던 sprint가 2주만에 마무리가 되었다.
그 중 내가 맡은 task는 반려동물 등록 flow를 몽땅 개선하는 것.

페이지 수로만 따지만 (꼴랑) 하나뿐이었지만...
지금껏 개발하며 배우고 느꼈던 걸 최대한 써먹으려 노력했다.

가장 마음에 드는 issue!
맨 처음 react-hook-form을 앱에 도입하면서
정확한 개념조차 잡히지 않은 채 재사용이 가능(할거라고 생각했던) 컴포넌트를 만들었는데...
props가 20개 남짓 넘어가는 걸 보며, 이를 다시 사용할 수는 없단 생각이 들었다.

 

따라서 UI 로직, form 관련 로직, react-hook-form 관련 로직이 몽땅 들어있던 컴포넌트를
각 기능을 담당하는 컴포넌트로 잘게 쪼개어 작성했다.

이를 통해 input의 공통 UI 변경 요구사항이 들어왔을 때 찾아갈 컴포넌트와,
onChange 이벤트 발생 시 상황 별로 다르게 동작할 로직을 작성할 컴포넌트와,
hook form의 errors를 다룰 때 찾아갈 컴포넌트를 분리할 수 있었다.
→ 당연히 이는 엄청난! 확장 가능 + 생산성 향상 으로 이어졌다.

 

단적인 예로... input별 unit label의 UI 변경을 배포 예정 당일 알게 되었는데,
이전이었으면 상황별 props를 확인하고... input의 각 사용처를 확인하고... 등등...
제법 긴 시간 소요 + 불안정성 으로 이어졌을 상황이 불과 몇 분만에 해결 가능했다!

관심사는 분리하고 보자!

하지만 여전히 고민인 사항도 많다.
그 중 하나 → 각 page별 비즈니스 로직은 어떻게 설계하면 좋을까?

해당 페이지의 edit 여부 판단, default data 세팅, submit function 작성 등...
이번 sprint에서 사용된 비즈니스 로직들은, 몽땅 해당 page 내에 작성을 했다.

 

물론 뚜렷한 문제를 발견하지는 못했지만...
이게 최선인가?하는 아쉬움이 남는 상태.

const PetRegistPage = () => {
	const handleFetch = () => ...
	const handleNavigate = () => ...
	const handleToastPopUp = () => ...
	const handleLog = () => ...

	const handleSubmit = () => {
      const inputData = ...

      try {
          await handleFetch() // 상황별 api request 제어
      } ... {}

      handleNavigate()
      handleToastPopUp()
      handleLog()
    	...
	}
    
    ...
    
    return (
    	<>
        	...
            <SubmitButton onPress={handleSubmit}/>
        </>
    )
}

PetRegistPage는 대략적으로 다음과 같은 모습!
해당 페이지가 동작하기 위한 로직들이 page 내게 작성되어있고,
view단에서 해당 로직들을 사용하기도, 토대로 UI를 그려주기도, props로 전달하기도 한다.

이 때 각종 상황 별(create인지, edit할 대상이 누구인지 등)로 수행될 기능들이 달라지다보니...
해당 상황을 swich해가며 필요한 동작을 수행하는 함수들이 점점 늘어나고,
이러한 함수들을 몽땅 page 내부에 작성하다보니 → 점점 길어지고 복잡해졌다 :(

생각나는 대안들로는

• usePetRegistHooks로 분리
  그리 좋다는 생각이 들지는 않았다. 왜?
  hooks를 함수형 컴포넌트에서도 상태를 관리하기 위해 사용하는데,
  내가 분리하고 싶은 비즈니스 로직들은 그저 상황별로 다른 기능을 수행하는 함수에 불과하니까!
  단순히 '페이지의 코드 길이가 길어지니' hooks를 만드는 느낌이 들었다.
  (심지어 해당 hooks를 다른 곳에서 재사용할 수도 없다! 그럴 용도로 만든게 아니기도 하고)
• 외부 단일 JS 파일로 분리 후 각 함수들을 export해 사용
  petRegistFunction.js란 파일을 만들어, pet regist에 필요한 함수들을 작성하면 되지 않을까?
  굉장히 좋다고 생각했지만...
  문제점은 pet regist에 필요한 함수들이 각종 hooks를 참조하고 있다는 것!
  (ex useDispatch, useNavigation ...)
  일반 함수에서는 hooks를 호출할 수 없기 때문에, 단순히 코드를 옮길 수는 없는 상황이었다.

어떤 방법이 최선인지는 아직도 고민 중이다만...
일단 2번 방안(petRegistFunction.js 분리)을 채택한 후,
hooks를 import해 사용하던 값들을 → 분리된 함수에 arg로 넘겨주면 되지 않나 하는 생각이 든다!

물론 이의 문제점은... 해당 arg의 정체가 무엇인지 알기 어렵다는 점!
(navigation이란 arg가 넘어왔다고 해서, navigation.gaBack() 메서드를 함부러 쓸 수는 없을테다)

따라서... 이는 TypeScript를 도입했을 때 유효하게 적용할 수 있을 것 같다!
→ 해당 인자들의 type을 지정해 안정성을 보장할 수 있겠지!

 

결론
1. 관심사 분리를 항시 고민하기
2. 비즈니스 로직 중 외부 변수를 참조하지 않는 함수들은 별도 파일로 분리하기
3. 외부 변수를 참조하는 함수들도 arg로 해당 값을 넘겨주기
(긴가민가... 적용해본 후 장단점을 고민해봐야겠다)