https://dolphin-pc.notion.site/9b914d1523fe4fa9bda697a6254cad49?pvs=4

[💥 트러블슈팅] 웹소켓에서 사용자 정보 불러오기

• 관련 커밋 : https://github.com/bocho-drive/back/commit/3861f10194107d6f7a0ef1758d515a7b9ccc59f0
• 웹소켓 URL : ws://localhost:8080/api/chat/msg/{chatId}
• Header : Authorization Bearer ~~

  📌 배경

• 웹소켓 연결 후, 사용자 정보를 불러오기 위해 SecurityContextHolder.getContext().getAuthentication()를 사용하였음
• 하지만, authentification은 null로 처리가 되고 있어, 이에 대해서 원인을 알아보고자 했다.
  • SecurityContextHolder.getContext().getAuthentication()에서 null이 발생하는 문제
  • Spring Security 인증 객체를 어떻게 가져올래?
  • websocket 환경에서의 securitycontextHolder
• 위 글로 도달한 결론은, Spring의 멀티 Thread환경으로 인해 SecurityContextHolder의 context가 공유되고 있지 않는다는 것이었다.

🎉 해결

• Debug모드로 실행해보니, WebSocketSession객체 안에 유저정보가 담겨있던 것이다..!!!!

• 이를 토대로, session객체에서 유저정보를 가져오는 메소드를 만들었다.

    /** 웹소켓 세션에서 사용자 정보를 가져오는 메서드 */
    public CustomUserDetails getUserDetails(WebSocketSession session) {
        Principal principal = session.getPrincipal();
        if (principal instanceof UsernamePasswordAuthenticationToken) {
            UsernamePasswordAuthenticationToken token = (UsernamePasswordAuthenticationToken) principal;
            return (CustomUserDetails) token.getPrincipal();
        }
        return null;
    }

• 이렇게 구현한 뒤, 채팅 테스트를 위해 postman으로 실행해보았다.

🤔 궁금증

1. SecurityContextHolder에 context가 공유되지 않는 구체적인 이유

• ws://localhost:8080/api/chat/msg/6로 웹소켓 Connect를 하면, JwtFilter에 도달하여, SecurityContextHolder.setContext(context);가 되는 것을 확인했다.
• 하지만, ChatWebSocketHandler.java의 afterConnectionEstablished메소드 함수에서 SecurityContextHolder.getContext()가 Null이 되는 이유를 Thread환경이 다르다는 것을 이해했지만, 정확한 원인을 알지 못하였다.

  2. WebSocketSession 객체에 사용자 정보가 담길 수 있었던 이유

• 해결방법 당시, session객체에 사용자 정보가 담겨져 있어 이를 get하여 해결하긴 했다.
• 하지만, session객체에 사용자 정보가 담길 수 있었던 원인을 제대로 파악하지 못했다.

Fact

• UI작업 완성 후, 게시글/댓글 API 연동 작업 진행
• https://github.com/orgs/bocho-drive/projects/2/views/1?sliceBy%5Bvalue%5D=2024-07-29

Feeling & Future

컴포넌트의 기준

• 공통 컴포넌트를 개발하던 중, 조건부 Props에 따라 다른 동작을 하려는 컴포넌트를 만들었다.
• 이에 기술매니저님께 피드백을 받아본 결과, 컴포넌트화 하려는 기준이 약하다는 의견을 듣게 되었다. https://github.com/orgs/bocho-drive/projects/2/views/4?pane=issue&itemId=72845899
• 앞으로는 컴포넌트를 설계하기 위해, ** 하나의 기능만을 수행하는 단일책임적인 원칙을 준수하고 간결한 코드 작성을 지켜가야겠다고 느꼈다. **

Tanstack Query, mutation

• react-query의 mutation 후, setQueryData, invalidateQueries를 수행하여, 새로운 데이터를 불러오기전 낙관적 업데이트 데이터를 보여주려 했다.
• 이러한 방법에 대해 매니저님께 피드백받은 결과, 데이터 무결성을 생각해야 하는 상황을 지양해야 한다는 의견을 듣게 되었고, 특수한 상황이 아니라면 refetch를 통해 새로운 데이터를 불러오는 것이 데이터정확성 측면에서 옳은 방법이라고 하셨다.
• 최적화, 성능적인 측면도 중요하지만, 정확한 데이터를 보여주는 것이 FE개발자로서 더욱 중요한 원칙이라는 것으로 받아들였다. https://github.com/orgs/bocho-drive/projects/2/views/4?pane=issue&itemId=72846258

Fact

• Github Projects로 개발진행상황 관리
  • https://github.com/orgs/bocho-drive/projects/2

Feeling & Future

• 앞으로 진행해야 될 내용들을 issue로 관리하고, Commit시 #이슈번호로 남기는 방식으로 개발을 진행했다.
• 이렇게 issue와 commit내역을 연동해놓으니, 차후 개발내용과 코드내용을 연결지어 확인할 수 있어 개발추적에 용이했다.

Fact

Level 5 완성

https://level5-cs-app.vercel.app/

팀 프로젝트 기획

• 아이디어 선정 & 유저플로우 분석
• API/기능 명세서
• MVP 구현범위 설정

Feeling

1. 제네릭 & 타입 제한

• 상황

  • addNewCsCard는 제네릭 함수로 T타입을 매개변수로 받을 수 있음

  • 매개변수를 그저 T 라고 선언할 경우, 함수 사용시 어떠한 타입도 들어갈 수 있는 문제 발생

  • 이는 정적 타이핑의 장점을 보지 못함

    export const addNewCsCard = async <T>(data:T) {}
    
    // 사용
    addNewCsCard<들어가면_안되는_타입>

  • 이를 방지하기 위해, T extends 사용

1. 제네릭에서의 extends 는 제한의 의미
2. 제네릭 T는 무엇이든지 받을 수 있지만, 그 범위를 제한하려면 extends를 사용하면 됨

참고 : https://inpa.tistory.com/entry/TS-📘-타입스크립트-Generic-타입-정복하기

// 함수 선언
export type NewAuthCardReq = Omit<ICsCard, "id"> & {
  userId: string;
};

export type NewCardReq = Omit<ICsCard, "id"> & {
  password: string;
};

export const addNewCsCard = async <T extends NewAuthCardReq | NewCardReq>(
  data: T
): Promise<ICsCard> => {
  if (data.password) data.password = encrypt(data.password);

  const res = await api.post<ICsCard>(BASE_URL, data);
  return res.data;
};

// 함수 사용

// 인증사용자의 Card추가
const onAddNewCardAuth = async (data: AuthCardFormSchema): Promise<void> => {
  if (!userId) return;

  const res = await addNewCsCard<NewAuthCardReq>({ ...data, userId });
  onSuccess(res.id);
};

// 익명사용자의 Card추가
const onAddNewCard = async (data: CardFormSchema): Promise<void> => {
  const res = await addNewCsCard<NewCardReq>(data);
  onSuccess(res.id);
};

2. zustand - store&공통기능 관리

• zustand로 global state와 공통기능을 정의하여, 여러 컴포넌트에서 재사용&일관된 상태관리를 할 수 있었음

3. react-hook-form & yup

• react-hook-form을 사용할 때, 검증기능을 사용하기 위해서는 input에 직접 validation을 붙여줘야 했음

<S.input.Input type="text" {...register("title", {required:true)} />
{errors.title && <S.span.ErrorSpan>제목을 입력해주세요.</S.span.ErrorSpan>

• 이럴 경우, validation의 재사용이 필요할 경우, 모든 input에 찾아가 수정해주어야 하는 문제 생김

yup resolver활용

// 사용할 schema 정의
import * as yup from "yup";

const title = yup.string().required("제목을 입력해주세요.");
const content = yup.string().required("내용을 입력해주세요.");

export const authCardFormSchema = yup.object().shape({
  title,
  content,
});
export type AuthCardFormSchema = yup.InferType<typeof authCardFormSchema>;

// form
  const {
    register,
    handleSubmit,
    formState: { errors },
  } = useForm<AuthCardFormSchema>({
    defaultValues: csCard,
    resolver: yupResolver(authCardFormSchema),
  });

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <label htmlFor="title">제목</label>
      <S.input.Input type="text" {...register("title")} />
      {errors.title && <S.span.ErrorSpan>{errors.title.message}</S.span.ErrorSpan>}
      <S.div.Gap $height={20} $width={0} />

      <label htmlFor="content">내용</label>
      <S.input.TextArea {...register("content")} />
      {errors.content && <S.span.ErrorSpan>{errors.content.message}</S.span.ErrorSpan>}
      <S.div.Gap $height={20} $width={0} />

      <S.button.Button $fullWidth type="submit">
        {isEditMode.current ? "작성" : "수정"}
      </S.button.Button>
    </form>

4. Suspense & useSuspenseQuery

• 보통 비동기 통신에 의한 렌더링은 IF 문을 통한 명령형으로 작성하곤 한다.
• 이를 선언형으로 변경하기 위해, React.Suspense와 useSuspenseQuery활용
  • 예전에는, useQuery의 옵션으로 {suspense:true}를 줘야 했지만, v5에서는 useSuspenseQuery로 따로 함수가 생겨남

// CardDetailPage.tsx <Suspense fallback={}>

CS카드

Fact

Level 4 - 인증/인가 활용 🔗

• PrivateRoute로 인증화면 분기
• Mixed Content, vercel proxy로 해결

Level 5 - 나만의 React앱 구현(구현중... 🔗)

• react-query활용

Finding

💥 Mixed Content 해결

• 서비스 배포 후(https적용), http API접근 시 오류 발생
• 해결을 위해 proxy로 우회하려 했으나, vite.config의 설정은 개발단계에서만 적용됨
• 운영 서버에서의 우회를 위해, vercel의 서버를 이용한 proxy활용
  • vercel.json을 작성하면, 경로를 rewrite해준다.

    // ./vercel.json
    {
    "rewrites": [
    {
      "source": "/api/:path*",
      "destination": "http://3.38.191.164/:path*"
    },
    {
      "source": "/api/:path*/",
      "destination": "http://3.38.191.164/:path*/"
    },
    { "source": "/(.*)", "destination": "/" }
    ]
    }

Zustand

• global state와 관련하여 새로운 라이브러리를 검색하다보니, zustand가 괜찮아 보였다.
• 그 이유로는,
  • 작은 번들 사이즈
  • provider 불필요
  • RTK와 같은 state와 action이 모여있는 형태
  • recoil과 같은 use함수의 사용방법
  • redux devtools 사용가능!

Atomic - Props drilling 보완

• Atomic 패턴을 활용해 컴포넌트를 쪼개다 보면, 불필요하게 props를 전달해주어야 하는 상황이 발생하게 된다.
• Props drilling을 보완해줄 수 있는 방법이 있는데, Compound방법이 있다.

  Compound

• 여러 개의 하위 컴포넌트가 하나의 부모 컴포넌트 안에서 작동하도록 하는 설계 방식이다.

  function App() {
  return (
    <Tabs>
      <Tab>Tab 1</Tab>
      <Tab>Tab 2</Tab>
      <Tab>Tab 3</Tab>
    </Tabs>
  );
  }

Feeling & Future

• Recoil, RTK가 state관리에서 주로 사용된다고 생각했지만, 큰 번들사이즈 늦은 업데이트 주기 등으로 인해 Zustand가 급격하게 인기를 얻고 있는 것 같다.
  • 앞으로 라이브러리를 선택할 때, 익숙한 것이 아닌 업데이트 주기 등을 고려하여 선택하는 것도 좋은 방법이 될 것 같다.
• Atomic패턴 개선
  • Atomic패턴을 도입할 때 만해도, 정리가 잘 되어가는 느낌에 이건 최고야..! 라고 느꼈지만, Props drilling, molecules<->organisms 경계모호 등의 문제를 보며, 좋은 패턴을 도입하더라도, 주관적인 기준을 확립하고 사용할 때 빛을 발하는 것 같다.

Fact

• React - redux styled-components react-portal

Level1 🔗

• Level1은 useState와 Props만을 이용했기에, 간단하게 구현함
  • props전달에 의한 re-render를 최소화하기 위해, useCallback과 React.memo를 활용하여 부모 컴포넌트의 변경에 따른 자식 컴포넌트의 re-render를 방지했다.
  • TodoCard에 전달되는 onToggleTodo, onDeleteTodo함수를 useCallback으로 메모이제이션하고, React.memo(TodoCard)로 감싸주었다.

Level2 🔗

• Level2 - redux을 이용한 todo list

  • Ducks패턴을 이용한 redux 함수 작성
  • atomic패턴을 이용한 폴더구조 활용

  📦src ┣ 📂components ┃ ┣ 📂atom ┃ ┃ ┣ 📜Button.tsx ┃ ┃ ┗ 📜Layout.tsx ┃ ┣ 📂molecules ┃ ┃ ┗ 📜TodoCard.tsx ┃ ┣ 📂pages ┃ ┃ ┣ 📜DetailPage.tsx ┃ ┃ ┗ 📜MainPage.tsx ┃ ┗ 📂template ┃ ┃ ┗ 📂TodoForm ┃ ┃ ┃ ┣ 📜TodoForm.tsx ┃ ┃ ┃ ┗ 📜index.ts

Level3 🔗

• styled-components를 이용한 Input, Button, Modal, Select컴포넌트 구현

  • atomic패턴의 컴포넌트 설계

  • S-Dot, $prefix를 통한 styled-component 설계

    📦src ┣ 📂assets ┣ 📂components ┃ ┣ 📂atom ┃ ┣ 📂molecules ┃ ┗ 📂template ┣ 📂styles ┃ ┣ 📜button.style.ts ┃ ┣ 📜index.style.ts ┃ ┣ 📜input.style.ts ┃ ┣ 📜row.style.ts ┃ ┗ 📜select.style.ts ┣ 📂util

    

    

    

Finding

• Ducks패턴을 통한, 코드의 관심사 집중방법
• Atomic패턴을 통한, 컴포넌트 재사용 방법
• styled-component의 Props를 통한 컴포넌트 재사용 방법

Feeling & Future

• Ducks, Atomic 패턴의 적용으로 코드의 규칙성을 부여하여, 코드가 급격하게 복잡해지는 문제를 방지할 수 있어, 디자인 패턴의 중요성을 깨닫게 되었다.
• styled-component로 Designed컴포넌트를 재사용하기 좋았다.
  • tailwind로 Designed컴포넌트를 공통화할 경우, props 전달로 인해 조합 사용이 좋지 못했다. 🔗
• 다양한 디자인 패턴을 알고 많은 라이브러리를 사용해보고 장단점을 알고 있는 것이, 앞으로 프로젝트 상황에 적합한 기술/패턴을 도입하는 데 유용할 것 같다.

Fact

• 팀원간의 페어프로그래밍을 통한 알고리즘 문제 코드 리뷰
• React 강의 시작 및 First 개인과제 시작

Feeling

• 코딩테스트 문제들은 프로그래머스 Lv 0-1수준이라 쉽게 넘겼다.
• 페어프로그래밍을 통해 다른 팀원의 코드를 보며, 다른 방식으로 풀 수 있다는 것을 보기도 했고, 내가 작성한 코드를 하나씩 설명하면서 정리가 될 수 있었다.

Finding

• 페어 프로그래밍에서 얻을 수 있는 장점은 2가지 인 것 같다.
  1. 다른 사람의 색다른 생각
  2. 내가 짠 코드를 설명하면서 정리해 볼 수 있는 기회
• 하지만, 팀원간의 기량 차이가 크다면, 2번밖에 얻을 수 없었다.

Future

• 새로 깨닫거나 배운 것은 없었던 것 같다.

Fact

이번주에 한 일

1. JS강의 복습
2. 야구게임 구현
3. (IT공채 지원서작성...)

Feeling

느낌

1. JS강의 - 사전학습과정에서 개념을 정리하고 간 터라 복습 진행할 필요를 느끼지 못함
2. 야구게임 구현
   • 분업하여 구현하기에는 기능의 개수가 너무 적어, 각자 야구게임을 직접 구현하기로 함
   • 나 포함 3명의 팀원이 각 브랜치에 완성된 코드를 PR하는 방식으로 진행

Finding

배운 것, 얻은 것

• Git Fork-PR을 통한 소스 contribute방법

Future

배운 것을 향후 어떻게 적용할 것인가

• Git Fork-PR을 통해 Git프로젝트의 팀원이 아니더라도 코드를 반영할 수 있는 방법을 배우며, 오픈소스 개발기여에 적용해볼 수 있을 것 같다.

마무리하며..

JS의 ES란

• ES, ECMAScript는 JS의 표준사양이다.
• 매년 업데이트되어 JS의 새로운 기능과 개선사항을 도입하며, ES5 ➡️ ES6때 가장 큰 변화가 있었다.
  • 대표적으로 let const 화살표함수 async/await 등이 있으며, 개발편의성과 관련한 내용이 가장 많았다.

ES5 vs ES6

1. 변수선언 let/const

   // es5
   var a = "";
   

// es6 let a = ""; const b = "";

2. 화살표 함수
```js
// es5
function func() { }

// es6
const func = () => {}

3. async/await

   // es5
   doSomething()
   .then(result1 => doSomethingElse(result1))
   .then(result2 => doAnotherThing(result2))
   .then(result3 => doSomethingMore(result3))
   

// es6 const result1 = await doSomething(); const result2 = await doSomethingElse(result1); const result3 = await doAnotherThing(result2);

```

• 번외 콜백지옥
  • 콜백지옥은 비동기 처리 뒤에 실행할 콜백함수를 지나치게 남발하여, 코드의 가독성을 해치는 경우이다.
  • 이러한 지옥은 가독성을 해치고 서비스의 유지보수성을 떨군다.
  • 그러므로, 비동기 처리를 할때는 되도록 Promise를 이용한 then()을 사용하거나 async/await를 사용하도록 하자

Fact

이번주에 한 일

1. 입학시험
2. 웹 미니 프로젝트 발제 및 개발 진행

Feeling

느낌

1. 입학시험 - 매우 쉬웠음
2. 웹 미니 프로젝트 - 오랜만의 협업개발이 재미 있었음

Finding

배운 것, 얻은 것

웹 미니 프로젝트 - flask도 JSP와 같이 include가 가능하다.

Future

배운 것을 향후 어떻게 적용할 것인가

flask는 사용할 일 없을 것으로 보임. (전통적인 Spring SSR방식)

마무리하며..

• 이번 주차에는 크게 배운 것을 써먹었다기보다, 기존에 알고 있는 지식으로 프로젝트를 잘 마무리했던 것 같다.
• Git협업, shell스크립트로 배포 자동화 등 기존에 알고 있던 것들을 잘 써먹었다.

• 개발 결과물 브로셔
• Github

• MVC, MVVM, Flux 등 코드의 아키텍처 종류에 대해 대략적인 특징만 알고 있었다.
• 이번 기회에 여러 아키텍처의 특징을 정리해보면서, 아키텍처의 변천사를 알아보고자 한다.

FE에서의 디자인 패턴

• 흔히들 알고 있는 디자인 패턴은 생성 구조 행동 패턴으로 분류된 개념을 떠올리곤 한다. 그래서 나 또한 위 디자인패턴을 가장 먼저 읽고 정리하게 되었고, 문득 아니 이건 객체에 대한 설명같은데, 프론트 보다는 백엔드 쪽에 가깝지 않나?!라는 생각이 들어 FE에서의 디자인 패턴을 조금 더 살펴보기로 했다.
• FE의 디자인 패턴은 결국 웹 디자인 패턴과 동일하게 풀이된다.
• 옛날의 웹은 백엔드를 중심으로 한 읽기전용웹이 전부였고, 단순한 패턴이 웹 디자인패턴의 시작이었다.

1. MVC 패턴

• 제일 유명한 패턴일 것이다. Model-View-Controller FE라는 개념이 없던 시절에는 웹사이트 자체가 View였기에, Model을 통한 View를 그려주는 매우 단순한 방식을 택했다.
  • 그렇기에 View > Controller -> Model -> View 방식으로 흘러간다.
  • 이에 대한 단점은 아주 명확한데, Model과 View이 끈끈하다는 것이다.
    • 대부분 운영환경의 경우, Model보다는 View쪽에서의 변경사항이 많이 발생한다.
    • MVC의 같은 경우, View의 수정이 필요할 때마다, Model의 변경또한 불가피해진다.

★ 초기에는 FE의 역할이 없어, Model을 통한 View를 그리는 매우 단순한 방식을 택했다.

⚠️ 매우 단순하지만, MVC간의 결합도가 높아

1. 코드 복잡성이 높고
2. 유지보수/테스트가 어려우며
3. 비즈니스 로직의 (관심사)분리가 애매한 상황이 존재할 수 있다.

2. MVP 패턴

• MVC패턴의 의존성을 낮추고자 나온 패턴으로, Model-View-Presenter 이다.
• Presenter가 Controller의 역할을 대신하지만, 흐름의 순서에 차이가 생긴다.
• View > Presenter > Model > Presenter > View 와 같이 Presenter가 완벽한 중개자가 된다.

★ MVC패턴에서의 뷰-모델간의 결합도를 낮춘다.

⚠️ Presenter의 역할이 중요해지면서, 결합도 또한 증가되었다.

3. MVVM 패턴

• 이제서야 초기 현대적인 디자인 패턴이 시작되었다.
• Model-View-ViewModel로, 이전의 MVP패턴과 달리 데이터바인딩이라는 개념으로 결합도를 조금 더 낮추게 한다.

✅ 데이터바인딩이란 View의 속성과 ViewModel의 속성을 연결하여, 유기적인 관계로 만드는 것이다. ex. 뷰모델의 userName속성과 뷰의 Input의 value 속성을 바인딩하면, userName이 변경될 때마다 TextInput의 값도 자동으로 변경되는 것이다.

• 이러한 데이터바인딩을 통해, View와 ViewModel의 연결을 확립하기에 MVP패턴보다는 결합도가 낮다고 말할 수 있다. (MVP에서 View와 Presenter가 태어날 때부터 짝꿍이었다)

★ MVVM은 데이터바인딩을 통해 UI와 비즈니스로직을 분리하여, 재사용성과 유지보수성을 높인다. 또한, 이러한 패턴은 현재의 FE 3대장인 React, Vue, Angular에서 초기개념으로 사용되었다.

⚠️ ViewModel의 설계가 어렵고, 학습곡선이 높다.

4. Component 패턴

• 인간의 욕심은 끝이 없듯이, 완벽에 가까운 MVVM패턴에서 더욱 재사용성이 높은 패턴을 찾게 되었다.
• 웹서비스가 발전하면서, 하나의 Page안에서 여러 모듈을 조립하는 방식인 Component패턴이 등장하게 되었다.

★ 재사용성, 모듈화, 독립성 등 컴포넌트를 기반으로 한 개발방식 (지금의 FE에 가깝다) 비즈니스 로직이 컴포넌트에 포함되면, 재사용성이 떨어지기에 UI와 비즈니스 로직을 분리하는 Container-Presenter 방식을 초기에는 활용하곤 했다.

⚠️ 컴포넌트 단위로 쪼개다 보니, 컴포넌트간의 유기적인 데이터관리가 어렵게 되었다. Props Drilling

5. Flux 패턴

• Component패턴은 props를 통해서만 데이터를 관리하다보니, 데이터의 파편화가 있었 다.
• 이를 해결하기 위해 store라는 전역저장소를 두어, 단방향적인 데이터흐름인 Flux패턴이 탄생하게 되었다.
• Action객체를 Dispatcher함수를 통해 Store에 반영하면, Store를 구독하는 View에 반영되는 흐름이다.

★ Props Drilling해소 전역상태관리 시대의 시작

⚠️ 높은 러닝커브 상태관리만을 위한 코드 (보일러 플레이트, Redux)

6. Observer-Observable 패턴

• 1:다 관계의 종속성을 정의하는 패턴이다.
• Flux와 비슷하나, Action과 Dispatch를 배제하여, 변경된 값을 모두에게 전달하는 방식이다.
• 초창기의 Mobx, RxJS

7. Atomic 패턴

• 지금의 Recoil이 따르고 있는 패턴
• Redux의 Flux패턴이 너무 장황하다고 여기게 되자, Model에 쉽게 접근하는 방법을 목표로 한다.
• Atom이라는 단위로 DataModel을 설계한다.

정리하며...

• MVC패턴부터 지금의 Component패턴까지 알아보면서 느낀점은 디자인 패턴은 불편한 것을 해결하거나, 더욱 나은 개선을 위해 진화해왔다는 점이다.
• MVC패턴의 불편함을 MVP로, MVP의 불편함을 MVVM으로 ...
• 하지만, Component패턴부터는 불편함보다는 더욱 나은 개선을 위해서인 것 같다. (물론, 보일러 플레이트나 높은 러닝커브 또한 불편함이라고 볼 수 있겠다..)

• 현재 많이 사용되고 있는 Redux, Recoil, React등이 이러한 디자인 패턴에 기인한 라이브러리인 것을 볼 수 있기에 디자인패턴에서 탄생될 라이브러리를 잘 활용하기 위해서는 디자인패턴에 대해 계속해서 알아보는 노력을 하는 것이 중요하다고 생각이 되었다.

객체간의 책임할당과 관련 어떻게 동작을 실행할 것인가?

1. 🔗 책임 연쇄(Chain of Responsibility)

• 요청이 들어왔을 때, 객체->객체 간의 이동을 반복하며 적절한 핸들러를 찾을 때까지 계속 이동
• 예시)
  • 결제수단이 1. 카드 2. 현금 3. 네이버페이 가 있을 경우,
  • 100,000원을 결제하려 한다.
  • 카드에서 100,000원을 결제한다 -> 하지만, 50,000원밖에 결제가 되지 않았다.
  • 2,3순위로 이동하여 결제를 계속한다.

2. 명령(Command)

• 명령할 인터페이스를 분리하여, 클라이언트에서 사용할 때, 명령을 전달한다.

// 전구를 리모컨으로 조작할 때의 경우

interface Command {
  exe(): void;
  undo(): void;
  redo(): void;
}

class Bulb {
  turnOn(): void {
    console.log("전구 켜짐");
  }

  turnOff(): void {
    console.log("전구 꺼짐");
  }
}

class TurnOn implements Command {
  bulb: Bulb;

  constructor(bulb: Bulb) {
    this.bulb = bulb;
  }

  exe(): void {
    this.bulb.turnOn();
  }

  undo(): void {
    this.bulb.turnOff();
  }

  redo(): void {
    this.exe();
  }
}

class RemoteControl {
  submit(command: Command) {
    command.exe();
  }
}

const bulb = new Bulb();

const turnOn = new TurnOn(bulb);

const remote = new RemoteControl();

remote.submit(turnOn);

3. 반복자(Iterator)

• 객체의 요소에 접근하는 방법을 제시하고, 내부 구조를 드러내지 않는다.

/**
 * @desc 라디오 채널을 예시로 한 코드
 */
class RadioStation {
  frequency: number;

  constructor(frequency: number) {
    this.frequency = frequency;
  }

  getFrequency(): number {
    return this.frequency;
  }
}

class StationList implements Iterable<RadioStation> {
  stations: RadioStation[] = [];
  counter = 0;

  addStation(station: RadioStation) {
    this.stations.push(station);
  }

  removeStation(station: RadioStation) {
    this.stations = this.stations.filter(
      (s) => s.frequency != station.frequency
    );
  }

  [Symbol.iterator](): Iterator<RadioStation> {
    return {
      next: () => {
        if (this.counter < this.stations.length) {
          return { done: false, value: this.stations[this.counter++] };
        } else {
          this.counter = 0;
          return { done: true, value: null };
        }
      },
    };
  }
}

const stationList = new StationList();
stationList.addStation(new RadioStation(100));
stationList.addStation(new RadioStation(200));
stationList.addStation(new RadioStation(300));

for (const station of stationList) {
  console.log(station.getFrequency());
}

stationList.removeStation(new RadioStation(200));

for (const station of stationList) {
  console.log(station.getFrequency());
}

4. 중재자(mediator)

• 두 객체 간의 상호작용을 제어하기 위해 중재자를 추가한다.
• 중재자패턴은 상호작용에 필요한 구현체를 알 필요가 없어, 객체간의 결합도를 줄일 수 있다.

/**
 * @desc 채팅방을 예시로 한 중재자 패턴
 */

interface ChatRoomMediator {
  showMessage(user: User, message: string): void;
}

class User {
  name: string;
  chatMediator: ChatRoomMediator;

  constructor(name: string, chatMediator: ChatRoomMediator) {
    this.name = name;
    this.chatMediator = chatMediator;
  }

  getName() {
    return this.name;
  }

  send(message: string): void {
    this.chatMediator.showMessage(this, message);
  }
}

class ChatRoom implements ChatRoomMediator {
  showMessage(user: User, message: string): void {
    const time = new Date().toLocaleDateString();
    const sender = user.getName();

    console.log(`${time} [${sender}]: ${message}`);
  }
}

const chatRoom = new ChatRoom();
const johnUser = new User("John", chatRoom);
const janeUser = new User("Jane", chatRoom);

johnUser.send("hi");
janeUser.send("hey there");

5. 메멘토(Memento)

• 객체의 상태를 어딘가에 저장해두고, 나중에 복원할 수 있도록 저장해두는 패턴이다.

/**
 * @desc 텍스트편집기의 예시로 메멘토 패턴
 */
class EditorMemento {
  protected content: string;

  constructor(content: string) {
    this.content = content;
  }

  getContent(): string {
    return this.content;
  }
}

class Editor {
  protected content = "";

  type(words: string) {
    this.content = this.content + " " + words;
  }

  save(): EditorMemento {
    return new EditorMemento(this.content);
  }

  restore(editorMemento: EditorMemento) {
    this.content = editorMemento.getContent();
  }

  print(): void {
    console.log(this.content);
  }
}

const editor = new Editor();

editor.type("hi");
editor.type("hello");

const editorMemento = editor.save();

editor.type("whatup");
editor.print();

editor.restore(editorMemento);
editor.print();

6. 옵저버(Observer)

• 객체 간의 의존성을 연결하여, 객체의 상태가 변경될 때마다 구독객체에 알림을 보낸다.
• (react에서는 흔히 알고 있는 전역상태관리, state가 변경되면 UI렌더링)

/**
 * @desc 구인구직을 예시로 한 옵저버 패턴
 */
class JobPost {
  protected title: string;

  constructor(title: string) {
    this.title = title;
  }

  getTitle(): string {
    return this.title;
  }
}

interface Observer {
  onJobPosted(jobPost: JobPost): void;
}

class JobSeeker implements Observer {
  protected name: string;

  constructor(name: string) {
    this.name = name;
  }

  onJobPosted(jobPost: JobPost): void {
    console.log(`Hi ${this.name}! New Job Posted: ${jobPost.getTitle()}`);
  }
}

interface Observable {
  notify(jobPost: JobPost): void;
  attach(observer: Observer): void;
  addJob(jobPost: JobPost): void;
}

class EmployeeAgency implements Observable {
  protected observers: Observer[] = [];

  // 옵저버 등록
  attach(observer: Observer): void {
    this.observers.push(observer);
  }

  // 새로운 직업이 등록된다면, 알림 발송
  addJob(jobPost: JobPost): void {
    this.notify(jobPost);
  }

  // 등록된 옵저버들에게 새로운 직업이 등록되었다고 알리기
  notify(jobPost: JobPost): void {
    for (const observer of this.observers) {
      observer.onJobPosted(jobPost);
    }
  }
}

const john = new JobSeeker("john");
const jane = new JobSeeker("jane");

const jobPoster = new EmployeeAgency();
jobPoster.attach(john);
jobPoster.attach(jane);

jobPoster.addJob(new JobPost("FE Engineer"));

7. 방문자(Visitor)

• 기존 객체를 수정하지 않고 새로운 작업을 추가하기 위한 패턴

  /**
  * @desc 동물원을 예시로 한 방문자 패턴
  * 방문자들에게 여러동물들의 묘기를 보여줘야 함
  */
  interface Animal {
  accept(operation: AnimalOperation): void;
  }
  

interface AnimalOperation { visitMonkey(monkey: Monkey): void; visitLion(lion: Lion): void; visitDolphin(dolphin: Dolphin): void; }

class Monkey implements Animal { accept(operation: AnimalOperation): void { operation.visitMonkey(this); }

shout(): void { console.log("우끼끼"); } }

class Lion implements Animal { accept(operation: AnimalOperation): void { operation.visitLion(this); }

roar(): void { console.log("ROAR"); } }

class Dolphin implements Animal { accept(operation: AnimalOperation): void { operation.visitDolphin(this); }

speak(): void { console.log("돌고래 울음소리"); } }

class Speak implements AnimalOperation { visitMonkey(monkey: Monkey): void { monkey.shout(); }

visitDolphin(dolphin: Dolphin): void { dolphin.speak(); }

visitLion(lion: Lion): void { lion.roar(); } }

const monkey = new Monkey(); const lion = new Lion(); const dolphin = new Dolphin();

const speak = new Speak();

monkey.accept(speak); lion.accept(speak); dolphin.accept(speak);

// 여기서, Jump라는 묘기를 추가한다면 어떡할까? // 아마 각 동물들을 수정해야 할 것이다. // 그러지말고, Jump라는 새 방문자를 만들어 보자 class Jump implements AnimalOperation { visitMonkey(monkey: Monkey): void { console.log("monkey jump"); }

visitDolphin(dolphin: Dolphin): void { console.log("dolphin jump"); }

visitLion(lion: Lion): void { console.log("lion jump"); } }

const jump = new Jump();

monkey.accept(jump); lion.accept(jump); dolphin.accept(jump);

### 8. [전략(Strategy)](https://soobing.github.io/cs/design-patterns-for-humans/#-%EC%A0%84%EB%9E%B5strategy)
- 상황에 따라 객체가 수행할 행동을 달리하는 것이다.
- 예를 들어, 엄청난 알고리즘을 적용했다고 하자.
  - 하지만, 이는 데이터의 양이 방대할 때만 유효하고, 데이터 양이 적을 때는 오히려 역효과가 발생한다고 가정하자.

> 전략 패턴은 상황에 따라 전략을 전환하는 패턴이다.

```ts
interface ISort {
  sort(dataset: number[]): void;
}

class BubbleSort implements ISort {
  sort(dataset: number[]): void {
    console.log("데이터의 수가 적을 때는 Bubble이 유용해요!");
  }
}

class QuickSort implements ISort {
  sort(dataset: number[]): void {
    console.log("데이터의 수가 많은 때는 QuickSort가 유용해요!");
  }
}

class Sorter {
  protected sorterSmall: ISort;
  protected sorterBig: ISort;

  constructor(sorterSmall: ISort, sorterBig: ISort) {
    this.sorterSmall = sorterSmall;
    this.sorterBig = sorterBig;
  }

  sort(dataset: number[]): void {
    if (dataset.length > 5) {
      return this.sorterBig.sort(dataset);
    }
    return this.sorterSmall.sort(dataset);
  }
}

const dataSet = [1, 2, 3, 4, 5];

const sorter = new Sorter(new BubbleSort(), new QuickSort());

sorter.sort(dataSet);

dataSet.push(6);
sorter.sort(dataSet);

9. 상태(State)

상태가 변경될 때, 클래스의 동작을 변경 객체가 특정상태에 따라 행위를 달리하는 상황에서, 조건문으로 행위를 달리하는 것이 아닌 상태를 객체화 하여 상태가 행동할 수 있도록 위임하는 패턴

• 상태는 state라는 변수로 관리하면서,
• 메소드(행동)에 따라, state에 update될 내용을 클래스로 만들어 낸다.

10. 템플릿 메소드(Template Method)

객체의 생성단계가 절대 변경되지 못할 때, 이 단계를 템플릿화하여 생성하는 패턴이다.

/**
 * @desc 프로그램 개발을 예시로 템플릿메소드 패턴
 */
abstract class ProgramBuilder {
  public build(): void {
    this.test();
    this.lint();
    this.assemble();
    this.deploy();
  }

  abstract test(): void;
  abstract lint(): void;
  abstract assemble(): void;
  abstract deploy(): void;
}

class AProgramBuilder extends ProgramBuilder {
  test(): void {
    console.log("AProgramBuilder test");
  }

  lint(): void {
    console.log("AProgramBuilder lint");
  }

  assemble(): void {
    console.log("AProgramBuilder assemble");
  }

  deploy(): void {
    console.log("AProgramBuilder deploy");
  }
}

const AProgram = new AProgramBuilder();

AProgram.build();

마무리하며...

• 생성, 구조, 행동 패턴에서의 다양한 디자인 패턴을 보며, 친근하게 느꼈던 패턴들이 많았다.
• 그럴만한게, 코드를 작성하면서 내가 고민했던 방식들이 이 디자인패턴들의 특징과 맞닿아있었기 때문이다.
  • 퍼사드 패턴 builder패턴 템플릿 패턴과 같이 코드의 복잡성을 낮추려 할 때 많이 사용했던 것 같다.
• 디자인 패턴을 알아보며, 코드를 작성하는 개발자에게는 디자인 패턴이라는 것은 고민의 흔적이라는 것이라고 느끼며, 디자인 패턴을 활용하는 일은 많지 않지만, 특별한 상황에서의 디자인패턴 활용은 해답이 되어주는 것 같다.
• 이처럼 디자인 패턴은 많이 활용되지는 않지만, 특별한 문제에 맞닥뜨렸을 때 아 ~~디자인 패턴 사용하면 될 것 같은데?!라고 떠올릴 정도로 개념만 익히고 가는 것이 좋다고 생각한다.

구조 패턴은 객체의 구성과 관련되며, Entity가 어떻게 사용될 수 있는지에 관한 것입니다.

1. 🔌 어댑터(Adapter)

어댑터 패턴을 사용하면 호환되지 않은 객체를 다른 클래스와 호환되도록 할 수 있다.

class Hunter {
  hunt(lion: Lion): void {
    lion.roar();
  }
}

// 이제 Hunter클래스는 Lion객체만 사냥할 수 있다.

interface Lion {
  roar(): void;
}

class ALion implements Lion {
  roar(): void {
    console.log("사자 죽어요");
  }
}

// 여기서, Hunter가 다른 동물도 사냥하고 싶다면 어떻게 해야 할까?

class Wolf {
  bark() {
    console.log("늑대 죽네");
  }
}

class WolfAdapter implements Lion {
  protected wolf: Wolf;

  constructor(wolf: Wolf) {
    this.wolf = wolf;
  }

  roar() {
    this.wolf.bark();
  }
}

// Usage
const hunter = new Hunter();

const lion = new ALion();

const wolf = new Wolf();
const wolfAdapter = new WolfAdapter(wolf);

hunter.hunt(lion);
hunter.hunt(wolfAdapter);

• hunter는 Lion객체만 사냥할 수 있다.
• 하지만, 다른 객체도 사냥할 수 있게끔, Wolf를 사냥할 수 있도록 Lion객체를 모방한 WolfAdapter를 통해, 사냥꾼을 변경하지 않고도 wolf를 사냥할 수 있게 만들 수 있다.

3. 브릿지(Bridge)

/**
 * @desc 브릿지 패턴
 *
 * 구현체에서 속성을 분리한다.
 *
 * 여기서는 [테마]에 따른 웹사이트 색상을 예시로 들어볼 것이다.
 *
 * 예를 들어, 페이지 A,B,C가 있고, 테마 1,2,3이 있다면 어떻게 할 것인가
 *   무식하게 한다면, A(1,2,3), B(1,2,3), C(1,2,3)을 모두 구현할 것이다.
 *
 * 여기서 브릿지 패턴을 적용한다면, 테마 1,2,3을 별도 분리하여, 활용할 때 가져다 쓰게 할 수 있다.
 */

// WebPage속성에서 Theme은 별도의 Type으로 빼놓는다.
type WebPage = {
  theme: Theme;
  getContent(): string;
};

class About implements WebPage {
  theme: Theme;

  constructor(theme: Theme) {
    this.theme = theme;
  }

  getContent(): string {
    return "About Page in " + this.theme.getColor();
  }
}

type Theme = {
  getColor(): string;
};

class DarkTheme implements Theme {
  getColor(): string {
    return "Dark";
  }
}

class WhiteTheme implements Theme {
  getColor(): string {
    return "White";
  }
}

// Usage
const dark = new DarkTheme();
const white = new WhiteTheme();

const aboutPage_Black = new About(dark);
const aboutPage_White = new About(white);

console.log(aboutPage_Black.getContent());
console.log(aboutPage_White.getContent());

Property를 별도분리하여, 활용할 때 조립하는 방식 추상화<->구현체를 분리

3. 컴포지트(Composite)

복합체 패턴, 복합객체와 단일객체를 동일한 컴포넌트로 취급하여, 클라이언트에게 이 둘을 구분하지 않고 동일한 인터페이스를 사용하도록 하는 구조 패턴 (...?, 명확히 이해가 되지 않는다)

• 아마도, 공통된 속성을 기반으로 활용할 수 있게 하는 패턴인 것 같은데,
• 예시를 들어보자면, 모든 사람들은 조금씩 다르지만 Age를 가진다 -> 20대가 몇명이지? 라고 구해볼 수 있는 것같다.

4. 데코레이터(Decorator)

객체를 Wrapping함으로써, 동적으로 객체를 변경할 수 있게 한다.

type Coffee = {
  cost: number;
};

class BasicCoffee implements Coffee {
  cost = 0;
}

class Americano implements Coffee {
  cost: number;
  constructor(coffee: Coffee) {
    this.cost = 20;
  }
}

class Latte implements Coffee {
  cost: number;
  constructor(coffee: Coffee) {
    this.cost = 40;
  }
}

let coffee = new BasicCoffee();

coffee = new Americano(coffee);
console.log(coffee.cost);

coffee = new Latte(coffee);
console.log(coffee.cost);

속성이 동일한 인스턴스에 한해서, 객체의 변경을 객체를 Wrap하여 바꾼다.

5. 퍼사드(Facade)

마치 물위의 백조와 같다

• 여러 동작들을 하나의 함수로 묶어서, 클라이언트가 사용하기 쉽게 단순화하는 패턴이다.
• 예를 들어, 컴퓨터를 켜본다고 생각해보자.
  • 우리는 컴퓨터 전원을 켜기 위해 전원버튼만 누르면 된다 (간단~)
  • 하지만, 컴퓨터 내부동작은 그렇지 않다.
    • 전원공급
    • bios세팅
    • os ...

class Computer {
  전원공급() {
    console.log("전원!");
  }
  소리내기() {
    console.log("소리!");
  }
  화면켜기() {
    console.log("화면!");
  }
  준비완료() {
    console.log("준비!");
  }
  BIOS세팅() {
    console.log("BIOS!");
  }
  OS() {
    console.log("OS!");
  }
}

class ComputerFacade {
  computer: Computer;

  constructor(computer: Computer) {
    this.computer = computer;
  }

  turnOn() {
    this.computer.BIOS세팅();
    this.computer.OS();
    this.computer.소리내기();
    this.computer.전원공급();
    this.computer.화면켜기();
    this.computer.준비완료();
  }
}

const computer = new Computer();
const user = new ComputerFacade(computer);

user.turnOn();

6. 플라이웨이트(Flyweight)

공유! 유사한 객체를 공유하여 메모리, 비용을 최소화

class Coffee {
  진함 = 0;
}

class CoffeeMaker {
  makedCoffee: Map<string, Coffee> = new Map();

  make(key: string): Coffee {
    // 만들어진 커피가 없다면, 커피를 만들어둔다.
    if (!this.makedCoffee.has(key)) {
      this.makedCoffee.set(key, new Coffee());
    }

    return this.makedCoffee.get(key)!;
  }
}

const coffeeMaker = new CoffeeMaker();

const coffeeList = [
  coffeeMaker.make("아메리카노"),
  coffeeMaker.make("라떼"),
  coffeeMaker.make("아메리카노"),
  coffeeMaker.make("아메리카노"),
];

// 하지만 객체공유 이기에, 다른 객체까지 영향이 간다.
coffeeList[0].진함 = 2;
console.log(coffeeList);

⚠️ 비용 최소화 관점에서 공유하는 것은 좋으나, 객체 변경에 따라 다른 객체까지 변경되므로 주의해서 사용해야 할 것 같다.

7. 프록시(Proxy)

하나의 클래스가 다른 클래스의 기능을 나타내는 것 👍 이런 경우에 활용할 수 있다.

• 특정 객체의 조건 확인
• 추가기능 제공

type Door = {
  open(): void;
  close(): void;
};

class HomeDoor implements Door {
  open() {
    console.log("Home Door Open");
  }

  close() {
    console.log("Home Door Closed");
  }
}

class SecureDoor implements Door {
  isLock = true;
  door: Door;

  constructor(door: Door) {
    this.door = door;
  }

  unLock(password: string) {
    if (password == "secret") this.isLock = false;
  }

  open() {
    // 프록시 패턴 : 조건 확인
    if (this.isLock) {
      console.log("Door is Locked");
    } else {
      this.door.open();
    }
  }

  close() {
    this.door.close();
  }
}

// 집에 문을 달았다.
const door = new HomeDoor();

door.open();
door.close();

// 하지만, 우리집은 누구나 열수 있기에, 도어락을 설치했다.
const secureDoor = new SecureDoor(door);
secureDoor.open();
// 이제 우리집은 암호를 풀어야만 열 수 있다.

secureDoor.unLock("secret");
secureDoor.open();

• 이노캠 필수과정 1일차, 기술매니저님이 Next, TS에 관해 여쭤보신 뒤 디자인 패턴에 대해 공부를 제시해주셨다.
• 안그래도, 사이드프로젝트를 진행하면서 왠지모르게 마음에 들지 않는 코드의 구조와 더 좋은 방법이 없나.. 라는 생각이 들던 참이었다.

디자인패턴

• 우리들을 위한 디자인 패턴
• 위 링크의 내용을 읽고, 이해한 내용을 써내려가보려 한다.

디자인 패턴이란

디자인 패턴은 반복되는 문제에 대한 해결책이며, 특정 문제를 해결하는 방법에 대한 지침이다.

디자인 패턴은 문제의 해결책이며, 문제를 찾는 해결책은 아니다. (...?)

디자인 패턴 종류

1. 생성 (Creational)
2. 구조 (Structural)
3. 행동 (Behavioral)

생성 (Creational) 패턴

객체 또는 관련된 객체 그룹을 인스턴스화하는 방법에 초점을 맞춘다.

1. 심플 팩토리

심플 팩토리는 클라이언트에게 인스턴스화 로직을 노출하지 않고 클라이언트용 인스턴스를 생성한다.

interface Door {
  getWidth(): number;
  getHeight(): number;
}

class WoodenDoor implements Door {
  protected width: number;
  protected height: number;

  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
  }

  getWidth(): number {
    return this.width;
  }

  getHeight(): number {
    return this.height;
  }
}

class DoorFactory {
  public static makeDoor(width: number, height: number): Door {
    return new WoodenDoor(width, height);
  }
}

// 위와 같은 팩토리가 있을 때, 클라이언트에서 인스턴스를 생성하는 법은 아래와 같이 하면 된다.

const door = DoorFatory.makeDoor(100,100);

👍 객체를 생성할 때, 일부 로직을 포함해야 할 경우 위와 같은 팩토리 패턴을 사용하면 좋다. 예를 들어, makeDoor에서 width와 height로 계산 로직이 들어갈 수도 있다.

2. 팩토리 메소드

자식 클래스에게 인스턴스화 로직을 위임하는 방식이다.

• 이게 무슨 소리인고하니, 예를 들어

  • 인사담당자라고 한다면,
  • 개발관련 면접관이 있을 것이고,
  • 소통관련 면접관이 있을 것이다.

• 이처럼, 여러종류의 면접관이 많을 것인데, 이것은 면접자에 따라 달라진다. (클라이언트에서 사용될 때(런타임)에 따라 특정 클래스에서 필요한 인스턴스를 받아야 한다.

• (팩토리 메소드, 해당 글을 보고 이해했다)

• 면접관 Class

  • 개발 면접관
  • 인사 면접관
  • 소통 면접관
  • 인성 면접관 등등 면접자에 따라 면접관 종류가 달라질 것이다.

• 이를 위해서, 면접관 Class에서 종류에 따라 필요한 면접관을 할당(인스턴스화)하려면 모든 조건에 따라 분기처리를 해주어야 한다. (이는 개방/폐쇄 원칙에 좋지 않다)

👍 필요한 인스턴스가 런타임에 동적으로 결정될 때 유용하다.

3. 추상 팩토리

구체적인 내용을 지정하지 않고, 관련된 것들을 그룹화한다.

interface Door {
    getDesc() : void; 
}

class ADoor implements Door {
     getDesc() {
          console.log("ADoor");    
    }
}

class BDoor implements Door {
     getDesc() {
          console.log("BDoor");    
    }
}

----

interface DoorMan {
     fix() : void;
}

class ADoorMan implements DoorMan {
     fix() {
        console.log('난 15달러');
    }    
}

class BDoorMan implements DoorMan {
     fix() {
        console.log('난 4달라');
    }    
}

---

interface DoorFactory {
     getDesc(): Door;
      fix(): DoorMan;
}


class ADoorFactory implements DoorFactory {
     getDesc(): Door {
          return new ADoor();
    }

      fix(): DoorMan {
         return new ADoorMan(); 
    }
}

class BDoorFactory implements DoorFactory {
     getDesc(): Door {
          return new BDoor();
    }

      fix(): DoorMan {
         return new BDoorMan(); 
    }
}

이처럼, Factory안에서는 구현내용없이, 관련된 내용을 그룹화하고 return하는 내용밖에 없다.

👍 상호 의존성이 있고, 복잡한 생성로직이 있는 경우 유용하다.

4. 생성자 (Builder)

• contructor의 오염을 방지하면서, 다양한 타입의 객체를 생성하기에 유용하다.
• 서브웨이에서 주문하는 방법과 비슷하다.
  1. 빵은 미디움으로 주시고요.
  2. 야채는 빼주시고,
  3. 치킨, 계란 넣어주시고,
  4. 15cm로 하고,
  5. 결제하고, 빵을 받는다.

// 생성자를 이용한 방식
class Burger {
  protected size: number;
  protected cheese: boolean = false;
  protected pepperoni: boolean = false;
  protected lettuce: boolean = false;
  protected tomato: boolean = false;

  constructor(builder: BurgerBuilder) {
    this.size = builder.size;
    this.cheese = builder.cheese;
    this.pepperoni = builder.pepperoni;
    this.lettuce = builder.lettuce;
    this.tomato = builder.tomato;
  }
}

class BurgerBuilder {
  public size: number;
  public cheese: boolean = false;
  public pepperoni: boolean = false;
  public lettuce: boolean = false;
  public tomato: boolean = false;

  constructor(size: number) {
    this.size = size;
  }

  addPepperoni(): BurgerBuilder {
    this.pepperoni = true;
    return this;
  }

  addLettuce(): BurgerBuilder {
    this.lettuce = true;
    return this;
  }

  addCheese(): BurgerBuilder {
    this.cheese = true;
    return this;
  }

  addTomato(): BurgerBuilder {
    this.tomato = true;
    return this;
  }

  build(): Burger {
    return new Burger(this);
  }
}

// 활용
const burger = new BurgerBuilder(14)
  .addPepperoni()
  .addLettuce()
  .addTomato()
  .build();

👍 객체의 생성이 여러단계에 걸쳐야 할 때 유용하다.

5. 프로토타입

객체를 복사하여, 새로운 객체를 생성한다.

• Object.create로 간단하게 수행가능하다.

  const original: Sheep = new Sheep("A");
  // original
  //   name : "A"
  //   category : "sheep"
  

const clone: Sheep = Object.create(original); clone.setName("B") // clone // name : "B" // category : "sheep"

> 👍 기존 객체와 유사한 객체가 필요하거나, 생성 비용이 많이 드는 경우 유용하다.


### 6. 싱글톤
> 특정 클래스의 객체가 한번만 생성되도록 한다.
⚠️ 싱글톤은 안티패턴으로 분류된다. 일부사례에서 유용하긴 하나, 주의해서 사용해야 한다.

- `생성자`, `복제`, `확장`을 `비활성화`하고, 특정 메소드로만 인스턴스 get이 가능하다.

```ts
// 대통령을 예시로 들어보겠습니다. (대통령은 1명 뿐이니)

class President {
     private static instance: President;

    private constructor() {}

    private clone(){}
    private wakeup(){}

    public static getInstance: President {
         if(!President.instance) {
             President.instance = new Presiden(); 
        }

      return President.instance;
    }
}

const president1: President = President.getInstance();
const president2: President = President.getInstance();

console.log(president1 === president2); // true

구조패턴은 다음편에...

• 4일차는 복습날, 오늘은 3주차 강의를 진행하는 날이다.

오늘 공부할것

• JS 3주차 : 데이터 타입(심화), 실행 컨텍스트, this

3-1. 데이터타입의 종류 및 메모리

• 기본형 (Primitive type)

  • Number
  • String
  • Boolean
  • null
  • undefined
  • Symbol

• 참조형 (Reference type)

  • Object
    • Array
    • Function
    • Date
    • RegExp
    • Map, WeakMap
    • Set, WeakSet

• 구분 기준

1. 복제여부

   • 기본형 : 값이 담긴 주소값을 바로 복제
   • 참조형 : 값이 담긴 주소값들로 이루어진 묶음을 가리키는 주소값을 복제

2. 불변성의 여부 (메모리 관점)

   • 기본형 : 불변성
     • 이게 무슨말이냐, let a=10이라고 했을 때, a=20 으로 했을 때 a변수가 가리키는 주소값 자체는 변경되지만, 10값이 할당된 메모리는 그대로 남아있다. (이후 가비지 콜렉터가 수거해감)
   • 참조형 : 불변성을 띄지 않음
     • 데이터 묶음을 가리키는 주소값 자체가 바뀌므로, 변동성이 있다고 볼 수 있음

• 메모리 : 비트, 바이트

3-2. 변수 선언과 데이터 할당(기본형데이터)

• 값 자체를 해당 주소에 저장하기 때문에, 값이 변경될 경우 주소값이 변경되지 값은 변경되지 않기 떄문에 (메모리 관점에서 불변하다) 라고 볼 수 있음
• 값이 새로이 추가가 될 경우에는, 해당 값을 데이터 영역에 새로 추가하고 그의 주소값을 a변수로 지정한다.
• 이를 데이터 관점에서 보았을 때, 값이 추가가 될뿐 변경이 되지 않아 불변하다라고 볼 수 있다.

3-3. 변수 선언과 데이터 할당(참조형데이터)

• 값의 묶음 주소값을 해당 주소에 저장하기 떄문에, 값이 변경될 경우 해당 주소값을 바꾼다.
• obj -> (obj의 값들을 가리키는 주소값) -> (obj의 실제 데이터가 있는 곳)
• obj의 값이 변경되었을 때, (obj의 값들을 가리키는 주소값) 이 부분이 변경되기에, 가변 하다라고 본다.

3-4. 불변 객체(얕은 복사 깊은 복사)

• 객체를 할당받는다면, 그것은 복사가 아닌 주소값을 공유한다 라고 볼 수 있다.

  const obj = {}
  const obj2 = obj;
  

console.log(obj == obj2) // true

- 그러므로, 객체를 공유받는 것이 아닌 값자체를 복사하려면 새로운 객체를 생성하고, 값을 하나하나 복사하는 수밖에 없다.
```js
const arr = [1,2,3];
function copy(arr) {
     let res_arr=[];
      arr.forEach(ele => res_arr.push(ele))
    return res_arr;
}

const arr2 = copy(arr);

console.log(arr == arr2) // false

• 중첩객체에 대해 모든 것을 복사하려거든, 재귀를 통한 깊은복사밖에 답이 없다. (아니면 JSON.stringify로 변환한 다음, 다시 JSON.parse 하던가

3-5. null과 undefined

• undefined : 정의되지 않음, 진짜 값이 없음 (개발자가 한거 아님)
• null : 정의되지 않음, 의도된 값이 없음을 의미 (개발자가 한 짓임)

3-6. 실행 컨텍스트 및 콜 스택

• 실행 컨텍스트? 코드가 실행될 환경정보가 있는 곳
• JS는 위->아래 순서로 코드를 읽어가면서, 값들을 스택으로 쌓아둔다. (=> 콜스택)

3-7/8. record와 호이스팅

• Context는 위->아래 순서로 Call Stack으로 쌓인다고 했는데, 쌓으면서 아래와 같은 짓을 한다.

1. VariableEnvironment 저장
   • 현재 컨텍스트의 식별자정보 저장, 변수a라는 놈을 기억하고 있겠다. (현재의 기억)
2. LexicalEnvironment
   • 선언적 어휘환경 저장, 선언된 시점에서의 데이터를 기억하고 있음 (태어날 때의 기억)
3. thisbinding
   • 그놈의 THIS!!! this가 바라봐야할 객체를 기억하고 있는다. (부모님을 기억하고 있는다고 보면 됨)

• 호잇!스팅 : 선언된 모든 것들은 머리채잡혀서 위로 올라가진다.
  • 하지만, const/class 같은 놈들은 TDZ라는 것에 의해 잡혀 올라가지더라도, 선언된 위치 이전에 사용하면 오류를 던져준다.

3-9. outerEnvironmentReference

• 3.6에서 콜스택 형태로, 모든 정보를 기억하고 있는 댔다.
• 콜스택으로 들어가기전, 자신의 조상을 기억하고 들어간다 (=>outerEnvironmentReference)
• 그 즉슨, 현재 Context에 없는 놈을 개발자가 찾으라고 명령한다면, 이놈들은 문밖으로 뛰쳐나가 어떻게든 찾아오려고 노력한다. (밖에 있는 경우에만 찾을 수 있음)
• 이것을 스코프 체인 이라고 한다.
• Inner -> Outer -> Global

3-10. 상황에 따라 달라지는 this

• this는 Function이 함수실행이냐, 메소드실행이냐에 따라 달라진다. (엥 이게 뭔 소리여)
• this가 정해지는 시점은 콜스택에 들어가는 시점이라고 했다.
• 그 즉슨, 함수가 실행되는 시점에 따라 this가 달라진다는 것인데 함수실행(독립적)으로 된다면 this는 Global을 가리키고, 메소드(객체에 붙어있는)으로 된다면 this는 객체를 가리킨다.
• 독립적 여부에 따라 this가 달라진다.
  • 내부함수 이더라도, 독립적으로 실행된다면 this는 global을 가리킨다.

3-11. this우회방법 콜백함수 this 생성자함수 this

this 우회방법

• this를 명시적으로 가리키기 위해, that/self 와 같은 변수에 this를 공유해두는 방법도 있다.

  let that = this;

• 또한, Arrow Function의 경우에는, ThisBinding이 포함되지 않아 독립적이든 아니든 선언시점에서의 this를 기억하고 있는다. (렉시컬 스코프)

콜백함수에서의 this

• this를 별도로 지정해주지 않았다면, this -> global 을 가리킨다.
• addEventListener 메소드의 경우, this는 메소드를 실행시킨 장본인을 가리킨다. (button.addEvent 였다면, this -> button을 가리킨다.)

new 생성자함수에서의 this

• new로 만들어진 놈은 인스턴스임
• new로 생성될 경우, 인스턴스 자신을 가리킴

3-12. 명시적 this바인딩 및 유사배열 객체

명시적 this바인딩

• call, apply, bind
  • call 메소드 실행시, 첫번째 인자에 this가 바인딩될 객체가 들어가고, 이후 값들은 개별적으로 들어감

    func.call(obj, 1,2,3,4);

  • apply 메소드는 call과 동일하나, 이후 값들을 배열로 묶어서 들어감

    func.call(obj, [1,2,3,4]);

  • bind 메소드는 call과 들어가는 것은 동일하나, 즉시실행되지 않고 바인딩된 값을 return 해준다. (나중에 이 함수를 실행하도록 저장해둘 수 있다.)

유사배열 객체

• 배열이랑 비슷하게 생긴 객체놈이 배열이랑 하는 짓을 똑같이 할 수 있음

  const 배열비슷하게_생긴_놈 = {
     0: '1',
      1: '2',
      2: '3',
      length : 3
  }
  

Array.prototype.push.call(배열비슷하게_생긴_놈, 'd') console.log(배열비슷하게_생긴_놈) // {0: '1', 1: '2',2: '3',3: 'd', length : 4 } }

```

3.13. call apply bind 응용

• call, apply는 this가 될 놈을 첫번째 인자로 넣어주면 되고
• bind는 call이랑 똑같으나, 지금 당장말고 나중에 실행되야 할때 쓰임

숙제. 실행 컨텍스트 더 알아보기

• this를 활용한 실행컨텍스트 문제

오늘 공부할것

• JS 2주차 1강 ~ 6강

1/2강 ES6 문법 소개 및 실습 (1/2)

• let, const
• 화살표 함수
  • this가 없어, 렉시컬 스코프에 의해 this가 바인딩된다. (선언 시점)
• 삼항 연산자 (? :)
• 구조분해할당
• 단축 속성명
  • 객체에 value를 지정할 때, key의 값과 value의 변수값이 일치하다면 skip이 가능함
• 전개구문 (spread, ...arr)
• 나머지 매개변수 (...args)
• 템플릿 리터럴 (``, ${})
• named export, default export

3/4강 일급개체로의 함수 (1/2)

• 일급객체란, 아래와 같은 조건을 만족할 때 일컫는 말이다.

1. 변수에 함수를 할당
2. 함수의 파라미터로 함수를 전달
3. 함수를 반환
4. 객체의 프로퍼티로 함수를 할당
5. 배열의 요소로 함수를 할당

• 이처럼, 함수가 일급객체로 취급되기 때문에, JS에서 함수를 매우 유연하게 사용할 수 있다.

5강 Map 소개 및 예시코드 연습

• key-value 형태의 객체
  • set() : 저장
  • get() : value 조회
  • delete : 키-값 쌍 삭제
  • clear : Map 내용 전체 삭제
  • size : Map 크기

6강 Set 소개 및 예시코드 연습

• 고유한 값만을 저장하는 배열(과 유사한형태)

숙제. 배열 연습하기

• 문자열의 특정 index번째에 따라, 배열 정렬문제

오늘 공부할것

• JS 1주차 9강 ~ 15강

9강. 조건문

• if, else if, else, switch, 삼항 연산자

10강. 조건문 중첩

• 조건문 중첩, || && 단축 평가
• falsy, truthy

  11강. 객체

• 객체, new 생성자를 통한 객체 생성
• Object, keys() values() entrise() assign()
• 객체 비교, 객체 병합

  12/13강. 배열 1/2

• [], Array
• push(), pop(), shift(), unshift(), slice(), splice(), forEach(), map(), filter(), reduce(), find(), some(), every(), sort(), reverse()

  14강. for문

• for, for-of, for-in, while, do-while

  15강. break continue

• break : 반복문 종료
• continue : 스킵

  숙제

  문자열 연습하기 반복문, 조건문 연습하기

오늘은 이노캠 개강전, 1.5주간의 사전준비과정에 돌입했다. 30분가량 강사님의 과정에 대한 설명을 간략히 듣고, 게더를 통해 4명의 팀원과 인사를 마치고, 각자 공부를 하고 7시에 다시 모이기로 했다.

오늘 공부할것

• 5/27(월) : 환경설정 및 1주차 1-8
  • JS, VS code 등 개발에 필요한 환경설정
  • 스파르타코딩클럽 1주차, 1강 ~ 8강

1. 환경설정

https://hh99.gitbook.io/onboarding-js/part-01.-hello-world/0.-../javascript

• Node.js, VScode

2. 스파르타코딩클럽 1주차, 1강 ~ 8강

1주차 주요 내용 : 자바스크립트 기본 문법

1주차 - 1강. 자바스크립트 소개

1. JS언어의 역사
2. JS언어의 특징
   1. 객체지향 프로그래밍 지원
      • Object {}
   2. 동적 타이핑
      • 런타임시, 변수의 타입 변동적으로지정
   3. 함수형 프로그래밍 지원
      • 일급객체 : 함수를 일반 값과 마찬가지로 변수에 할당하거나, 함수의 인자로 전달/반환값으로 사용할 수 있는 객체
   4. 비동기 처리
      • 동기적이지 못한(ex. API통신) 구간에 대한 응답을 기다리지 않고, 병렬로 처리할 수 있도록 하는 방식
   5. 클라이언트/서버 측 모두 사용가능
      • JS의 모태는 웹 브라우저에서 사용하기 위했지만, Node.js의 발전으로 인해 서버측에서도 사용이 가능함

1주차 - 2강. 변수와 상수

• 변수 : var let const
• 상수 : const

1주차 - 3/4강. 데이터 타입

• 데이터 타입 : 숫자, 문자열, 불리언, undefined, null, Object, Array

1주차 - 5강. 형변환

• 암시적 형 변환 : JS에서 자동으로 수행되는 형 변환, 일반적으로 연산자를 사용할 때 발생
  • 문자열 변환
  • 숫자 변환
  • 불리언 변환
• 명시적 형 변환 : 직접 자료형을 변환하는 것
  • 문자열 변환
  • 숫자 변환

1주차 - 6강. 연산자

• 산술연산자 : + - * / %
• 할당연산자 : = += -= *= /= %=
• 비교연산자 : == === != < >
• 논리연산자 : && ||
• 삼항연산자 : ? :
• 타입연산자 : typeof

1주차 - 7강. 함수

• 함수 선언문

  function add(x,y) {}

• 함수 표현식

  let add = function (x,y) {}

1주차 - 8강. 스코프와 화살표 함수

• 스코프(scope)란, 현재 실행되고 있는 Context로 값이 표현되거나 참조될 수 있는 환경을 말함.

  • 전역 스코프 (Global scope) : 어디서든 참조할 수 있는 환경
  • 지역 스코프 (Local scope) : 특정 함수안에서만 참조할 수 있는 환경
  • 블록 스코프 (Block scope) : if, for문과 같이 {}에 둘러쌓여 있는 환경

• 화살표 함수

  • 화살표 함수는 ES6문법에서 나온 것으로, 함수선언을 =>지정어로 간결하게 표현할 수 있으며 내부적 this바인딩이 존재하지 않아, 중첩함수안에서 사용될 경우, 렉시컬 스코프에 의해서 this는 선언된 객체를 가리킨다. (화살표 함수가 선언된 곳의 객체가 this가 된다)

• Code Snippet이란, 자주 사용되는 코드 조각을 말한다.
• 단축키로 하여금, 코드를 불러올 수가 있다.

// rafce

import React from 'react'

const page = () => {
  return (
    <div>page</div>
  )
}

export default page

VS code 설정

1. Commands+Shift+P 로 커맨드 패널을 연다.

2. Configure User Snippets 선택

3. 코드 스니펫이 적용될 위치를 적용한다.

4. 코드 스니펫의 제목을 작성한다.

5. 코드 스니펫 작성

• 객체의 제목 : 구별할 수 있을 정도로만 적당히 작명한다.
• prefix : 스니펫을 불러올 단축어
• body : 스니펫 코드

  $1 $2 와 같은 특수지정어가 존재하는데, 이는 코드 스니펫을 읽어온 직후 사용자의 cursor를 해당 위치하게 해준다.

TIP : 코드 스니펫 본문을 작성할 때, ``(백틱이 불가능하다) https://snippet-generator.app/ 이 사이트를 이용하면 본문코드를 snippet으로 변환해준다.

배경

• 특정Tab을 클릭하면, Accordion 컴포넌트의 open state값을 변경시켜 Accordion을 열고자 했다.
• 아래 이미지를 보면, Tab제목이나 Accordion버튼을 클릭할 때마다, 모든 컴포넌트가 재렌더링되는 문제가 있었다.

소스구조

1. 바탕이 되는 컴포넌트 TabScroll는 useTabScroll(hooks)에서 Recoil데이터를 선언하고, Tab제목컴포넌트와 Accordion컴포넌트를 하위 자식으로 가진다.

// TabScroll.tsx
const TabScroll = ({
  groupLikeStockList,
}: {
  groupLikeStockList: TGroupLikeStockInfo[];
}) => {
  // [registryRef]의 tabIndex로 스크롤될 컴포넌트의 ref배열에 등록한다.
  // [handleScroll]로 지정된 컴포넌트 클릭시, ref배열의 위치로 스크롤 및 ref컴포넌트의 Accordion을 열어준다.
  const { registryRef, handleScroll, headerRef } = useTabScroll({
    length: groupLikeStockList.length,
  });
  ...
  return (
    ...
    // Tab제목 컴포넌트
    {groupLikeStockList.map((group, idx) => {
        return (
            <Button key={idx} tabIndex={idx} onClick={handleScroll}>
                {group.groupName}
            </Button>
        );
    })}
    ...
    // Accordion컴포넌트
    {groupLikeStockList.map((group, idx) => {
        return (
          <div key={idx} tabIndex={idx} ref={registryRef}>
            <Section.Accordion
              index={idx}
              title={group.groupName}
              noContent={<Button primary>주식 추가하기</Button>}
            >
              {group.likeStockInfoList.length &&
                group.likeStockInfoList.map((likeStock, idx) => {
                  return (
                    <div
                      key={idx}
                      className="flex items-center justify-between"
                    >
                      <p>
                        {likeStock.name} ({likeStock.stockId})
                      </p>
                      <Button primary>BUY</Button>
                    </div>
                  );
                })}
            </Section.Accordion>
          </div>
        );
      })}
  )
}

// useTabScroll.ts | hooks함수
export const useTabScroll = ({ length }: { length: number }) => {
    const [isOpenTabList, setIsOpenTabList] = useRecoilState(tabOpenStateList);

    // 버튼 클릭시, ref에 등록된 element로 스크롤 이동
    const handleScroll = (e: MouseEvent<HTMLButtonElement>) => {
        const tabIndex = e.currentTarget.tabIndex;
            ...
            setIsOpenTabList(() => {
                const newState = [...isOpenTabList];
                newState[tabIndex] = true;
                return newState;
            });
        }
  };
})

// 

2. recoil의 atom에는 tabOpenStateList가 등록되어있다.

   export const tabOpenStateList = atom<boolean[]>({
   key: "tabOpenStateList",
   default: [],
   });

문제원인

• Tab을 클릭할 때마다 실행되는 setIsOpenTabList부분에서 recoil의 전체 상태값이 변경되어, 모든 컴포넌트가 재렌더링된다고 생각되었다.

  setIsOpenTabList(() => {
    const newState = [...isOpenTabList];
    newState[tabIndex] = true;
    return newState;
  });

• 그래서 이러한 isOpenTabList state배열을 잘게 잘라서 사용할 수 있도록 selectorFamily를 활용하였다.

적용

// atoms/tab.ts
import { DefaultValue, atom, selectorFamily } from "recoil";

export const tabOpenStateList = atom<boolean[]>({
  key: "tabOpenStateList",
  default: [],
});

export const tabOpenState = selectorFamily({
  key: "tabOpenState",
  get:
    (tabIndex: number) =>
    ({ get }) => {
      return get(tabOpenStateList)[tabIndex];
    },
  set:
    (tabIndex: number) =>
    ({ set }, newValue: boolean | DefaultValue) => {
      set(tabOpenStateList, (prev) => {
        const newState = [...prev];
        if (!(newValue instanceof DefaultValue)) {
          newState[tabIndex] = newValue;
        }
        return newState;
      });
    },
});

• 이처럼 TabIndex값에 따라 tabOpenStateList에서 특정요소만 get/set할 수 있도록 설정했다.

활용

// useTabScroll.ts
  const setOpenList = Array(length)
    .fill(false)
    .map((_, idx) => useSetRecoilState(tabOpenState(idx)));
...

// 버튼 클릭시, ref에 등록된 element로 스크롤 이동
  const handleScroll = (e: MouseEvent<HTMLButtonElement>) => {
    const tabIndex = e.currentTarget.tabIndex;
    if (tabBodyRef.current) {
      (tabBodyRef.current[tabIndex] as HTMLDivElement).scrollIntoView({
        behavior: "smooth",
        block: "start",
        inline: "nearest",
      });
      setOpenList[tabIndex](true);
    }
  };

• 위와 같이, tabOpenState selectorFamily를 배열의 수만큼 setOpenList변수에 미리 할당해둔다.

  이처럼 적용한 이유! handleScroll함수가 실행될 때, 비로소 openState값이 바뀌어야 하기에 useSetRecoilState를 함수내부에서 사용할 수 있도록 미리 선언해주어야 했다.

  React hooks의 선언 규칙은 항상 최상단에서 이루어져야 하기에, 위와 같이 setOpenList에 미리 담아주었다.

• 자주 접하는 에러...
• 이처럼 적용하고, Accordion 컴포넌트에서도 index에 맞는 selector를 가져오도록 작성해주었다.

그 결과!

• 다음과 같이, tab클릭 & accordion버튼 클릭 시에도, 해당 컴포넌트만 re-render되도록 최적화할 수 있었다!!

수정된 소스코드

https://github.com/Dolphin-PC/motoo/commit/500f93424fbf21b188545aa5dd7745d6f57f21ed

2024.05.23 수정

• selectorFamily -> atomFamily로 수정
• 처음에는 atom으로 선언된 배열에 대해서, get/set을 할 수 있는 selectorFamily를 사용했다.
• 하지만, selectorFamily와 atomFamily의 기능이 거의 유사한 것을 알 수 있었고, 이는 사용목적에 따라 구분되어 있다는 것을 알 수 있었다.
  • atomFamily : 동적인 키를 가진 atom의 집합 (동일한 상태를 공유해야 하는 여러 컴포넌트에 용이)
  • selectorFamily : 동적인 키를 가진 selector의 집합 (atom값에 계산을 하거나, 비동기작업을 수행하는 데 사용)
• 이를 보았을 때, 내 상황에서는 atomFamily가 적합하다고 생각하여 코드를 리팩토링했다 (더 간결해졌다!)

  // atoms/tab.ts
  

export const tabOpenStateList = atomFamily<boolean, number>({ key: "openList", default: () => false, }); // atom관련한 코드가 이렇게 짧아졌다.

```

3줄 요약

• 특정 Tab을 클릭하면 Accordion이 열리게 하고 싶어, recoil을 사용했다.
• 하지만 atom(배열)로 OpenState를 관리하고 있어, 특정요소가 update되면 전체 페이지가 re-render되는 문제 발생
• 이를 atomFamily로 수정하여, OpenState(atom 집합)로 특정 컴포넌트만 re-render되도록 수정