0803
https://news.hada.io/topic?id=22301
ㄷㄷ
슬롯 컴포넌트
- 슬롯 컴포넌트를 사용하면 정해진 위치에 원하는 컴포넌트를 삽입할 수 있다.
- 이게 뭔 말이지?
- ppt 템플릿을 예시로 생각해보자.
- ppt를 만들 때 모든 슬라이드의 왼쪽 위에는 회사 로고를 달고,
중앙 하단에는 페이지 번호가 들어가게 디자인 하고 싶다고 가정하자. - 근데 이 때 매 슬라이드마다 일일이 회사 로고와 페이지 번호를 복붙하면 겁나 귀찮을거다.
- 그래서 ppt엔 슬라이드 마스터 라는 기능이 있다. 이걸 쓰면 만드는 사람은 이제 안에 있는 콘텐츠 내용만 신경 쓰고 레이아웃 디자인은 신경을 안 써도 된다.
- 이게 뭔 말이지?
- vue에는 슬롯 컴포넌트라는 개념이 있는데, React에는 이게 없다.
- 그래서 react에선 props를 활용해 각 요소에 대한 매개변수를 넘겨주고 그걸 받아오는 형태로 작성하거나 reduce를 사용해 children에서 각 부품을 추출하는 형태로 슬롯 컴포넌트를 구현할 수 있다.
- 에 근데 next에선 layout이란게 있잖아요
- 맞다. 그래서 next의 layout을 쓰는게 슬롯 컴포넌트 개념을 사용하는거랑 동일한? 확장된? 의미다
추상화
- 추상화란 뭔가
- 복잡한 로직을 하나의 간단한 함수나 클래스로 묶어서 나타내는 것
- 왜 필요한가
- 복잡한 로직을 알 필요가 없을 때
- 아니 근데 어차피 버그 터지면 전체 로직 알아야 되는거 아님? 왜 굳이 추상화 해야되지?
- 추상화를 하면 버그가 터져도 어디서 터졌는지 빠르게 알 수 있어서 유지보수가 쉬워짐
- 추상화 한다고 성능상 이점이 있나?
- cost가 들 때도 있고, 아닐 때도 있다.
- 근데 웬만해선 추상화는 효율성을 높여주기에 사용하는게 좋다.
Sometimes, even though there might be an additional function call, it really does not matter. As long as you pick the right algorithms and data structure, even if it is hiding behind some abstraction, it will still perform just as well.
Sometimes an abstraction can even help performance. If you abstract some code and as a result, you end up reusing code, you might end up hitting the instruction cache more often, which can dramatically help performance.
참고 자료: https://www.quora.com/Does-abstraction-always-make-a-system-slower-or-more-expensive
그럼 나는 언제 추상화하고 컴포넌트를 분리하는가?
- 추상화든 컴포넌트든 하나의 역할만 하도록 최대한 잘개 쪼개는듯?
코드를 작성할 때는
- 역할을 나누고 (컴포넌트 분리)
- 그 역할에 이름을 붙여서 (컴포넌트, 훅)
- 복잡한 내부 구현을 숨기고 (추상화)
- 다른 곳에서 쉽게 가져다 쓸 수 있도록 (재사용성)
하는 것이 중요하다
etc
- https://velog.io/@teo/functional-programming
- 이건 객체지향과 함수형 프로그래밍에 대한 글인데 나중에 읽어보고자 스크립을. . .