안녕하세요. 저는 프론트엔드 개발자 이건학입니다.
최근에 제가 관심있어하는 관심 분야가 있는데요?! 현재 회사 내부에서 꾸준히 개발하고 있는 별이되어라2 게임 운영툴을 만들면서 view, model 을 최대한 분리하는 작업을 꾸준히 하고 있습니다.
그 이유에 대해서 이제 설명해볼까 합니다.
A or B 라는 Object 가 들어온다는 가정의 컴포넌트
type Props = {
A?: {id: string, name: string, age: number}
B?: {id: string, name: string, age: number, job: string, ...}
}
export function index({A, B}:Props){
const [obj, setObj] = React.useState(null)
const [viewText, setViewText] = React.useState<string>('')
const {data: bData, status: bDataStatus} = useGetBDataQuery()
React.useEffect(() => {
if(A !== undefined) {
getDataFetch({id: A.id, name: A.name, age: A.age})
} else if (B !== undefined) {
setViewText(`${B.name} ( ${B.id} ${B.age} )`)
setObj(B)
}
}, [])
React.useEffect(() => {
if (bData && bDataStatus === 'fulfilled') {
setViewText(`${bData.name} ( ${bData.id} ${bData.age} )`)
setObj(bData)
}
}, [])
return (
<button onClick={e => onClickHandle(e, obj.age)}>
{viewText}
</button>
)
}
JavaScript
복사
아주 쉬운 예시코드입니다. “A”라는 Object 가 있고, “B”라는 Object가 있습니다. 이때 “A, B”를 보면 “A”의 데이터를 포함하고 있는게 ”B”라는걸 유추해 볼 수 있을 것 같습니다. 그렇습니다 “A”는 “B”의 Summary 데이터 입니다.
이런식의 데이터 핸들링을 하게 되는 경우에는 한 곳에서 관리를 할 수 있고 이 데이터의 모양에 따라 따로 데이터 핸들링을 함으로써 전략 패턴 (Strategy Pattern)과 비슷하게 동작할 수 있을 것 같습니다.
이 때, 저는 실제로 문제를 만났습니다…. 바로 id, name만 존재하는 경우입니다. 이런 경우에는 getData()를 하기에는 age라는 데이터가 필요한데, 계속해서 페이지와 기능들이 늘어나면서 새로운 기능에서 컴포넌트를 불러와서 “B”를 보여주고 onClick() 이벤트를 실행해야하는데… id, name만 가지고 있는 경우가 생겼습니다.
이 문제를 해결하기 위해 제가 선택한 방법은 무조건 “B”만 들어와서 랜더링만 책임지는 컴포넌트를 만드는 방법을 채택했습니다.
이렇게 채택함으로써 장점은 어떠한 데이터 유형이 있더라도 결국 보여줘야하는 컴포넌트의 데이터가 B라면 밖에서 무슨 짓을 하든 “B”의 View를 책임지는 컴포넌트는 “B”만 props로 넘겨주면 정상작동을 한다는 것 입니다.
B 가 무조건 들어온다는 가정의 컴포넌트
type Props = {
B: {id: string, name: string, age: number, job: string, ...}
}
export function index({B}:Props){
React.useEffect(() => {
if (bData && bDataStatus === 'fulfilled') {
setViewText(`${bData.name} ( ${bData.id} ${bData.age} )`)
setObj(bData)
}
}, [])
return (
<button onClick={e => onClickHandle(e, B.age)}>
{`${B.name} ( ${B.id} ${B.age} )`)}
</button>
)
}
JavaScript
복사
위에 코드처럼 간결하게 바뀔 수 있다는 겁니다. 실제로 이렇게 해서 재사용이 가능하게 구현을 해 여기저기서 불러와서 사용할 수 있게 만들었으며, 이런 패턴을 프레젠테이셔널 패턴(Presentational Pattern)이라고 하더군요.
이렇게 사용함으로써 밖에서 어떤 다른 작업을 하더라도 결국 “B”라는 데이터를 보여줘야할땐 “B”의 View 담당하는 담당일진(?)이 생김으로써 “B”만 나올 수 있게 관심 분리를 통해 일관된 데이터 흐름을 볼 수 있는 것 같습니다.
플로우차트로 보면 조금 더 편하겠죠?
이렇게 보면 플로우 차트에서 제가 원하던 B를 그리는 과정이 조금 더 간결해졌다고 생각합니다. 그리고 "B"를 출력하는 컴포넌트 밖에서는 무엇을 하던 B를 보기위한 유저 이벤트가 발생한다면 일관되게 데이터를 보여줄 수 있다고 생각합니다.
물론 단점도 있다고 생각합니다. 유연한 대처가 어려울 수 있거나. 비슷한 패턴의 컴포넌트가 많아진다면 관리가 어려워질 수 있다고 생각합니다.
그리고 저는 디자인 패턴이라는것에 몰두해서 만들진 않았습니다. 제가 생각하고 문제를 해결했던게 비슷한 디자인 패턴이 이런거구나 하고 공부하는 거죠..?
아무튼 제가 현업에서 문제를 만나 해결했던 해결법이였습니다! 긴 글 읽어주셔서 감사합니다.