Slider 컴포넌트

PrevButton, NextButton 중복 로직

시도한 방법

PrevButton, NextButton으로 구현
- 장점: 하나의 컴포넌트가 하나의 역할만 하므로 코드를 예측하기 쉬워지고, 분기문이 필요없어 가독성이 좋다. 버튼을 사용할 때 PrevButton, NextButton이라는 name 딱 보여 사용자 측면에서는 좋을 수 있다.
- 단점: 중복 로직이 생기고, 두 버튼이 함께 사용하는 옵션이 수정될 경우 두 컴포넌트 모두 수정해야하여 유지보수가 힘들다.
중복 로직을 하나의 함수로 빼보기
- 시도해봤으나 하나로 빼려면 두 컴포넌트가 함께 쓸 수 있게 컴포넌트 외부로 꺼내야하니 인자가 많아진다.
- prev냐 next냐에 따라 분기를 해줘야해서 다시 분리를 했다.
하나의 버튼 컴포넌트로 합쳐 direction을 prop으로 받기
- 두 개의 버튼으로 관리하면 전체적으로는 비슷한 로직이다 보니 옵션들이 변경되거나 할 경우 두 버튼 모두 수정해줘야해서 하나로 모아서 관리하는게 편할 수 있다.
- 위의 중복 로직을 빼는 방법처럼 내부에서 분기가 필요하다.
- 장점: 중복 코드를 줄이고 하나의 컴포넌트로 유지보수가 편리하다.
- 단점: 분기문으로 인해 가독성이 떨어지고 하나의 컴포넌트가 여러 역할을 하여 (길이가) 커진다.

고민할 사항

파크: prev, next 가 아니라 다른 기능이 또 필요하다면?
- prev, next, button 컴포넌트를 따로 만들어 prev와 next가 상속받아 사용하는 방식으로 추상화하는 방법은?
  - 해당 방법도 결국 기존의 PrevButton, NextButton을 구현한 방식에서 버튼을 분리한 것이다. 중복 로직을 줄이는 해답인지는 의문.
- 1번, 2번 해결 방법 모두 버튼이 추가될 경우 분기문이 추가되어 오히려 더 혼란스러워진다.

결론

옵션 변경될 일이 많지 않고, 후에 버튼이 추가될 경우 분기문이 복잡해진다. 가독성이 좋은 것 또한 유지보수에 좋은 일이다.

Context value 의 type 네이밍

Park: value라는 이름까지 붙여줘야할까? 그냥 타입을 따로 빼지 않고, 배열 자체를 createContext의 인자 타입으로 적어두는게 타입이 잘보여서 좋은거 같다.
```
const DropdownContext = createContext<
  [DropdownState, Dispatch<DropdownAction>]
>([initState, () => {}]);
```
Dony: props만을 내려주는 용도로 사용해야 할 때는 context의 value가 배열이 아니다. props들을 묶어서 context의 value 길어도 정확한 네이밍이 좋다고 생각해서 ContextValue라고 타입 이름을 지었다.
```
type SliderInfoContextValue = {
  options: SliderOptions;
  SlideLength: number;
};

export const SliderInfoContext =
  createContext<SliderInfoContextValue | null>(null);
```

결론

type SlideIndexState = {
  currentIndex: number;
};

type SliderIndexContextValue = [
  SlideIndexState,
  Dispatch<SetStateAction<SlideIndexState>>,
];

export const SlideIndexContext =
  createContext<SliderIndexContextValue | null>(null);

xxxContextValue로 따로 빼서 사용
state와 setState(dispatch)의 배열을 context의 value로 사용해야할 때는 state는 객체인 경우 따로 빼서 정의하고, setState(dispatch) 타입은 따로 빼지않고 xxxCotextValue 타입 안에서 바로 사용.

Slider? Carousel?

slider는 input range를 칭하는 용어로 정의되어있다.