web/components-should-be-flexible/
utterances-bot opened this issue · comments
변경에 유연한 컴포넌트 | JBEE.io
이번 포스트에서는 변경에 유연하게 대응할 수 있는 컴포넌트에 대해 이야기해보려고 한다 TL;DR 컴포넌트는 데이터를 중심으로 추상화한다. 일반적인 인터페이스로 컴포넌트를 디자인한다. 변경에 유연하다는 것 우리가 작성하는 소프트웨어는 지속가능해야 한
Single SourthSource of Truth 오타같습니당
좋은 글 잘 읽었습니다 🙏
좋은 글 감사합니다 :)
많은 인사이트 얻고 갑니다 !
좋은 글 감사합니다.
글 내용 중 궁금한 점이 있어서 질문드립니다.
List Item 컴포넌트는 재사용, 확장할 수 있게 되었지만 li 태그를 사용하는 것과 다른 게 없지 않나? 하는 의문이 생겼습니다. li를 사용하지 않고 List Item 컴포넌트로 분리함으로써 얻을 수 있는 이점이 있나요?
@SoLO95 읽어주셔서 감사합니다 :)
li를 사용하지 않고 List Item 컴포넌트로 분리함으로써 얻을 수 있는 이점이 있나요?
예제 코드에서는 li 태그만 사용되는 것처럼 작성됐는데, 여러 가지 스타일들이 재사용된다고 보시면 좋을 것 같습니다 :) 그리고 그 스타일들을 조건에 따라서 다르게 렌더링 되는 부분을 관리하는 역할로 보시면 될 것 같아요
평소 많은 고민을 하고있던 내용인데 다뤄주셔서 기쁘네요!
덕분에 어느정도 생각을 정리할 수 있게된것 같아요.
한가지 궁금한점이 생겼는데, 그렇다면
추상화 작업을 하는것과 유연한 컴포넌트로 분리 한다는 것은 서로 다른 리팩토링 과정이라고 봐도 될까요..?
안녕하세요 :) @sangmin802
추상화 작업을 하는것과 유연한 컴포넌트로 분리 한다는 것은 서로 다른 리팩토링 과정이라고 봐도 될까요..?
제가 질문을 제대로 이해한 것인지는 모르겠지만, 두 가지를 분리하는 것이 의미가 있나? 라는 의문이 들었고 여쭤보신 두 작업에 대해서 굳이 답변을 드리자면, 같은 작업이라고 생각합니다.
아아.. 죄송합니다.. 제가 질문을 이상하게 한 것 같네요..
처음에, 추상화에 있어 역할과 책임을 설명해주시고, 데이터, 역할 기반으로 컴포넌트를 분리해주신 이후에, 재사용 가능한 컴포넌트로 설계되었는지 파악하고 수정하는 과정을 설명해주셨는데요,
최종 결과물에서 생성된 두가지 컴포넌트들의 디렉토리 위치를 보았을 때, ListItem은 재사용 가능 하기 때문에, components 디렉토리에 배치 하셨고, AddressList는 비교적 그렇지 않기때문에 pages/address 디렉토리에 배치 하셨다라는 생각을 했습니다.
사실 이러한 기준으로 배치를 하신것인지도 궁금합니다..
- ListItem : 데이터를 UI로 표현하는 역할 만을 수행하도록 추상화 되고, 재사용 가능하게까지 설계된 컴포넌트
- AddressList : 외부에서 데이터를 받아오는 역할 만을 수행하도록 추상화된 컴포넌트
AddressList처럼 모든 컴포넌트들이 유연하고 재사용가능하게 설계되는것은 어렵고, 모든 추상화된 컴포넌트가 재사용가능한것은 아니기 때문에 유연하게 컴포넌트를 설계한다는것을 추상화를 하는것과 다른 작업 이라고 이해를 했던것 같습니다..
그래서
추상화 작업을 하는것과 유연한 컴포넌트로 분리 한다는 것은 서로 다른 리팩토링 과정이라고 봐도 될까요..?
라는 질문을 드렸던것 같아요.. 죄송합니다..😭
혹시 제가 잘못 이해한것일까요..
@sangmin802 답변이 너무 늦어버렸네요 ㅠㅠ
AddressList는 비교적 그렇지 않기때문에 pages/address 디렉토리에 배치
네! Address라는 도메인 맥락이 있기 때문이라고 할 수 있을 것 같네요! 다만 추후 address라는 도메인을 여러 page에서 공유하게 될 경우, modules라는 별도 top level directory에서 관리할 수 있을 것 같습니다.
AddressList처럼 모든 컴포넌트들이 유연하고 재사용가능하게 설계되는것은 어렵고,
AddressList는 사실, 재사용 목적으로 분리했다기 보다는 AddressPage 컴포넌트의 복잡도를 낮추기 위해 분리한 컴포넌트라고 할 수 있겠어요.
유연한 컴포넌트로 분리하기 위해 추상화한다. 라고 생각해요~
좋은 글 너무 잘읽었습니다!
좋은 글 감사합니다!
좋은 글 감사합니다
혹시 출처를 남기고 후기나 제 생각을 블로그에 정리해도 괜찮을까요???
좋은 글 감사합니다 혹시 출처를 남기고 후기나 제 생각을 블로그에 정리해도 괜찮을까요???
@yoonminsang 네, 물론입니다! :) 저도 그 글 공유받을 수 있을까요?ㅎㅎ
글에서 정말 많이 배웠습니다! 혹시 저도 공유해주신 내용을 개인 프로젝트에 적용해보고 그 과정을 정리해서 블로그에 (출처와 함께) 올릴수 있을까요~?
좋은 공유 감사합니다.
글에서 정말 많이 배웠습니다! 혹시 저도 공유해주신 내용을 개인 프로젝트에 적용해보고 그 과정을 정리해서 블로그에 (출처와 함께) 올릴수 있을까요~?
네~ 여기 댓글에도 공유해주세요! 저도 읽어볼게요!
감사합니다. 정말 컴포넌트를 바라보는 시야를 넓힐 수 있었습니다. :)
질문이 있어서 댓글을 남깁니다~
Q. SaveAddressButton과 그 안에 있는 handleSaveClick()의 경우, domain에 종속되어 있는거 아닌가요? 해당 부분에 실제 코드가 들어간다고 생각해보면(어디에 save된 정보를 저장할테니), domain에 종속적이지 않나요?
안녕하세요, @Laeyoung 님 :)
Q. SaveAddressButton과 그 안에 있는 handleSaveClick()의 경우, domain에 종속되어 있는거 아닌가요? 해당 부분에 실제 코드가 들어간다고 생각해보면(어디에 save된 정보를 저장할테니), domain에 종속적이지 않나요?
질문의 의도가 무엇일까요? domain free하다는 문장이 있었나요? 아래와 같은 내용이 있어서요.
그런데 SaveAddressButton과 같이 주소 도메인과 강하게 결합되어 있는 컴포넌트를 직접 가져와 사용하는 부분이 있어서 컴포넌트 이름과 props 이름을 변경해도 소용이 없다.
아 안녕하세요~~😃
변경에 유연한 컴포넌트가 "그렇기 때문에 반복되는 요소들을 매번 개발하기보다는 미리 만들어둔 요소를 재사용하여 여러 가지 이득을 취할 수 있기 때문에 컴포넌트로 개발하곤 한다."
라는 말에 공감을 하는데요. A와 B에서 어떻게 재사용 할 수 있을지 궁금해서요. 예를 들면, Meta에서 변경에 유연한 SaveButton 컴포넌트를 하나 만들어서 Facebook과 Instagram 양쪽에 쓰다면, 위에 방식으로 어렵지 않을까 싶은데 좋은 방법이 있을까요?
안녕하세요~
재엽님 글을 인상깊게 보아서 제 생각을 블로그에 정리하고 싶은데 출처 남기고 작성해도 괜찮을까요?
안녕하세요! 저번에 여쭤봤던 개인 프로젝트에 적용하는 부분 블로깅 하게되어서 공유 드립니다!ㅎㅎ jbee님의 글을 읽고 이번 프로젝트에서는 그동안의 개발 경험에서 아쉬웠던 점을 개선하고 발전할 수 있는 기회로 삼고 싶었습니다. 아쉬웠던 점으로는 기능이 추가될 때마다 유지보수가 어려운 코드가 생산되었던 점을 꼽았고, 이에 대한 보완사항으로 공동 인터페이스로 사용하는 컴포넌트에는 도메인 맥락을 제거하고, 상세한 데이터를 그려내는 컴포넌트는 도메인별로 구분하여 작성/관리하는 방식을 도입했습니다. 또한 타입스크립트를 도입하여 형식을 미리 체크하고, TDD 도입을 공부해 보았습니다. 생각한 것을 적용하기 위한 액션 아이템을 정해 보았는데 관련 내용을 블로그에 적어 보았습니다.
https://dahna.tistory.com/3
그 결과로 프로젝트도 하게 되었는데요, 프로젝트 관련 내용은 여기에 작성해 보았습니다!
https://dahna.tistory.com/7
배포된 프로젝트 주소입니다!
https://eatwhat.kr/
공유해달라고 하셨는데 미루다 이제야 글을 쓰네요ㅎㅎ
https://ms3864.tistory.com/433
강연도 잘 보고 글도 잘 읽고 갑니다.
저도 radix-ui와 antd의 소스코드를 뜯어보며
좋은 컴포넌트 설계에 대해 나름의 고민은 해봤지만,
성자님처럼 domain-agoinstic한 컴포넌트 관점에서 생각은 못해본것 같군요
깊이와 내공이 느껴지는 글이었습니다.
혹시 해당 아티클을 작성하면서 참고하신 사이트나 아티클이 있으시면 공윱 부탁드려도 될까요?
감사힙낟.
@Hong-JunHyeok 그럼요! :)
@ioboihyeoki 감사합니다.
혹시 해당 아티클을 작성하면서 참고하신 사이트나 아티클이 있으시면 공윱 부탁드려도 될까요?
딱히 참고한 아티클은 없어요!
여러 번 읽으니까 처음에는 이해가 되지 않던 부분도 이해가 되고 있습니다! 이런 좋은 글을 읽을 수 있게 해주셔서 감사합니다!
와 대박이네요🫢 평소에 고민되던것들이 담겨있어서 많이 배운거 같습니다!
코드 깔끔하게 짜는것도 좋은데, 생각하신 내용들이 대단하신거 같습니다
좋은 글 감사합니다!
좋은 글 감사합니다!
아직은 이해가 되지 않은 부분도 있어서 여러번 읽어봐야겠어요 :)
막상 개발을 할때는 내가 변경에 유연하게 대처할 수 있는 컴포넌트를 개발하고 있는가 계속 의구심이 드네요ㅠㅠ
컴포넌트의 역할 중 외부로부터 주입된 데이터를 관리한다고 하셨는데 만약 내비게이션바라는 컴포넌트를 만들때 각 버튼에 대한 text도 데이터로 바라보면서 Array로 관리하는 것도 좋은 방법이 될 수 있을까요?
내비게이션바라는 컴포넌트를 만들때 각 버튼에 대한 text도 데이터로 바라보면서 Array로 관리하는 것도 좋은 방법이 될 수 있을까요?
상황에 따라 다를 것 같아요 ㅎㅎ
Array로 관리하면 네비게이션 아이템 중 하나가 다른 모습이어야 할 때 귀찮을 것 같네요.