1주차 Discussion

[chloe-codes1]

📢 책을 읽으면서 궁금한 점들을 자유롭게 적고 대답해 주세요

1주차 진행 방식

• 진도: 3장까지 읽어오고 정리 & 의견 나누기

[sunhpark42]

BombMan으로 간단히 실습해봐도 좋을것 같아요~!

[ddongule]

혹시 bomb guy?!

[sunhpark42]

bomb guy 였군

[sunhpark42]

@chloe-codes1 getCommentByParentIdAndDirection 함수 명에 대해 이야기 해보면 좋을 것 같아요~!

[sa02045]

1. 함수 나누기

• 함수 두개로 나누어서 사용하기
• 성능관점에서는 안 좋을 것 같음

// 1. comment1과 comment2로 나누어서 가져온 다음 공통 원소 찾기
const comment1 = getCommentByParentId(id)
const comment2 = getCommentByDirection(direction)



// 2. chaning할 수 있다면 chaning하기
const comment = getCommentByParentId(id).getCommentByDirection(direction)

2. 데이터 추상화 (SICP - 데이터추상화에서 했던 그것...)

• ParentId + Direction을 추상화된 데이터로 바라보기
• 추상화된 데이터로 바라본다면 함수 인터페이스측면에서는 ParentI와 Direction에 대한 의존을 끊을 수 있기 때문에 함수명에도 제거해도 될 것 같음
• 데이터가 2개 이상이거나 변화에 대응하기에는 좋은 것 같음
• 참고) https://stackoverflow.com/questions/20157141/method-naming-getx-by-multiple-parameters

// 이것 보다는
getCommentByParentId(parentId, direction)


// params라는 추상화된 데이터로 바라보기
const params = {
   parentId,
   direction
} 

// 아예 By~를 없애버리거나
const comment = getComment(params)

// 또는 ByParams 붙이기 (이름은 적당히 추상화된 무언가로)
const comment = getCommentByParams(params)

// 자바는 잘 모르지만 이런식으로??
class Parmas {
	int parentId;
        int direction;

	Parmas (int parentId, int direction) {
		this.parentId = parentId;
                this.direction = direction;
	}
}


Parmas parmas = new Parmas(parentId, direction) 
getComment(parmas)


만약 다른 조건이 추가된다면??
함수명은 그대로 두고 params 객체만 바꾸면 됨

const params = {
   parentId,
   direction,
   foo,
   bar,
   ....
} 

const comment = getComment(params)

3. 그냥 쓰기 ^^

• 조건이 2개라면 getCommentByParentIdAndDirection 함수명도 괜찮은 것 같음
• 조건이 2개이상이라면? 2번 방법을 고민해볼 것 같음

[sunhpark42]

상속 / 컴포지션

[sunhpark42]

https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html

[sa02045]

React 컴포넌트 합성 (Composition) vs 상속 (Inheritance)

• https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750

• https://ko.legacy.reactjs.org/docs/composition-vs-inheritance.html

• https://legacy.reactjs.org/docs/design-principles.html#composition

• 이미 React는 상속대신 합성 모델을 밀고 있었음

- 리액트의 핵심 기능인 컴포넌트의 합성입니다. (- 리액트 설계 원칙 중)
- Facebook에서는 수천 개의 React 컴포넌트를 사용하지만, 컴포넌트를 상속 계층 구조로 작성을 권장할만한 사례를 아직 찾지 못했습니다.
- React에서는 이 역시 합성을 통해 해결할 수 있습니다. 더 “구체적인” 컴포넌트가 “일반적인” 컴포넌트를 렌더링하고 props를 통해 내용을 구성합니다.

• 그러나 Hook의 등장으로 합성 모델도 잘 안쓰게되는 듯
• 상속 -> 합성 -> Hook

// 일반적인 컴포넌트
function Dialog(props) {
  return (
    <FancyBorder color="blue">
      <h1 className="Dialog-title">
        {props.title}
      </h1>
      <p className="Dialog-message">
        {props.message}
      </p>
    </FancyBorder>
  );
}

// 구체적인 컴포넌트
function WelcomeDialog() {
  return (
    <Dialog
      title="Welcome"
      message="Thank you for visiting our spacecraft!" />
  );
}

Vue는 상속에서 합성으로 뒤늦게 넘어감

https://ko.vuejs.org/api/options-composition#extends

• vue에는 여전히 컴포넌트 상속 기능이 있었음(extends, mixin)
• Composition API을 도입하면서 상속 대신 합성으로 넘어가기 시작함

여기서 로직 재사용에 대한 합성이란 React Hook과 동일하다고 생각하면 될듯 (React 컴포넌트 합성이랑은 다른 얘기)
- (Composition API에서는 로직 재사용에 대해 "상속(inheritance)"보다는 "조합(compose)"이 선호되는 개념 모델입니다)

// CompB.vue 파일에서

import CompA from './CompA.vue'

export default {
  // CompB 컴포넌트는 CompA에 정의된,
  // 옵션 속성들을 상속받음
  extends: CompA,
  ...
}

[yunseorim1116]

어려운 코드를 다룰때 (예시로 애니메이션같은) 주석달기 vs 문서화 하기

[yunseorim1116]

주석 달기: 로직이 바뀌었을 때 주석도 같이 챙겨야해서 결국 레거시가 되는 경우가 많을수도.
문서화 하기: 위키도 마찬가지로 별반 다르지 않을 수도.. 버전 업데이트를 해야 하니까?