서론
오늘의 이야기는 과제가아닌 컴포넌트에 대한 이야기다.
과제를 바닐라JS로 진행하였지만, 결국 기능을 한데 모으고, 재사용이 가능한 컴포넌트식으로 만들었다.
따라서 컴포넌트와는 뗄레야 뗄 수 없는 관계.
멘토님이추천해주신 강의 영상을 보며 컴포넌트란 무엇이고, 어떻게 만들어야하는지 배워보겠다!
컴포넌트
의존성을 최대한 없애자.
스타일,로직을 한군데 묶어서 관리. => css-in-js, presenter-container
리모트 데이터와 스키마 의존성 관리 => 프롭스로 데이터를 받지말고, id를 받아와 데이터저장소에서 id를 통하여 해당 데이터를 가져오자.(의존성 끊기)
하지만id만으로 가져오기는 힘들 수 있음.
이때 필요한게 정규화(normalization)하여 id기반으로 정리
//이렇게 되어있는 구조라면, 아이디 기반으로 데이터를 가져오기 힘들 것이다.
{
id: 123,
author:{
id:1,
name:"kim"
},
title:"my title",
comments:[
id:324,
commenter:{
id:2,
name:"lee"
}
]
}
//정규화 해보기
{
result:123,
entities:{
articles:{
id...
},
users:{
1:{...},
2:{...},
},
comments:{
324:{id:324...}
}
}
}아래와 같은 구조라면
response.entities.원하는모델명(articles,users...).id
이런식으로 뽑아내기 굉장히 유용하다
이를 도와주는 라이브러리도 당연히 존재. normalizer라고 있음!
하지만, 여기에는 또다른숨은 의존성이 생긴다.
=> 상위 컴포넌트가 원하는 모델을 정확히알고 있어야함.
이를 해결하기위해 전역 ID(유니크)도입이 필요하다.(해시쓰던가 하쇼잉)
이름짓기
간단한 유저프로필을 보여주는 컴포넌트가 있다고 가정해보자.
이 컴포넌트는 다음과 같은 의존성을 가질거다
=> 의존한다면 그대로 작명하자
//의존하는 그대로 작명했다.
props:{
userImageThumbnailUrl,
userName,
userFollower,
userNickName,
}
//유저와 이미지 사이의 관계정보를 더 정확히 해보자
user:{
name,
nickname,
followr,
img:{
thumbnailUrl,
}
}
//관심사를 분리해보자
user:{
name,
nickname,
followr,
}
img:{
thunbnailUrl,
}
//위처럼 두 컴포넌트로 분리 가능하지만, 모양을 정확히 맞춰야하기에 재사용성이 떨어진다.
//id만 받아오는 건 어떨까?
user:{
userId,
}
img:{
imgId,
}
useNode({
on:'Article',
fields:{
title:true,
content:true,
}
},
props.articleId)
//필요한 필드는 따로 커스텀 훅을 만들어 처리한다.재사용하기
이렇게 재사용 가능한 컴포넌트는 왜 필요할까?
정확히 개발 단계보단, 변경 할때굉장히 용이하다!
FE는 결국 데이터를 받아와 처리하기에, 리모트 데이터 스키마에 따라 모양이 결정된다.
=> 모델 기준으로 컴포넌트를 분리하자
- 같은모델을 의존하는 컴포넌트 : 재사용
- 다른 모델을 사용하는 컴포넌트 : 분리
4원칙 지키기
- 비슷한 관심사는 가까운 곳에
- 데이터를 ID기반으로 정리하기
- 의존한다면 그대로 드러내기
- 모델 기준 컴포넌트 분리하기
관점이 기술보다 중요하다. 정답만을 좇지말고, 질문을 해라!
느낀점
과제를 진행하며 컴포넌트에 대해 알게되었고 재사용 가능한 컴포넌트의 중요성도 뼈저리게 느꼈다.
또한 전역 스토어의 도입이 필요하다는 것도 느꼈고 특히 오늘 공부했던 4원칙에대해 많이 배웠다.
이제는 재사용 가능한 컴포넌트를 어떻게 작성하고, 의존성 분리를 어떻게 해야하는지 조금은 알 것 같다.
코드리뷰를 받고나서 리팩토링 진행할때 무조건 도입해봐야지!
