Refactor/#308: 사용자의 전공 상태 정보(useState) 삭제

[hwinkr]

🤠 개요

• closes : Refactor: 사용자의 전공 정보 상태(useState) 삭제 #308
• 사용자의 전공 정보를 상태(useState) 로 관리할 필요는 없다고 판단해서 로컬 스토리지에 의존하는 클래스를 구현해서 관리하는 것으로 변경 했어요.

💫 설명

interface IMajorStorage {
  getMajor: () => string | null;
  setMajor: (major: string) => void;
}

class MajorStorage implements IMajorStorage {
  private TOKEN_KEY;

  constructor(key: string) {
    this.TOKEN_KEY = key;
  }

  getMajor() {
    const major = localStorage.getItem(this.TOKEN_KEY);
    return major;
  }

  setMajor(major: string) {
    localStorage.setItem(this.TOKEN_KEY, major);
  }
}

클래스를 사용해서 로컬 스토리지에 저장한 사용자의 전공 정보를 관리하고,

const MajorProvider = ({ children }: MajorProviderProps) => {
  const majorStorage = new MajorStorage(MAJOR_STORAGE_KEY);

  return (
    <MajorContext.Provider value={majorStorage}>
      {children}
    </MajorContext.Provider>
  );
};

MajorProvider 컴포넌트는 해당 클래스를 의존성으로 주입해줬어요. 주입 받는 컴포넌트들은 동일하게 useMajor 훅을 사용해서 전공 정보를 참조할 수 있어요

📷 스크린샷 (Optional)

[pp449]

전공값 조회/수정을 모두 localStorage 를 이용하는데 Provider 로 굳이 감싸지 않고 Util 로 사용하는건 어떤가요??

[hwinkr]

전공값 조회/수정을 모두 localStorage 를 이용하는데 Provider 로 굳이 감싸지 않고 Util 로 사용하는건 어떤가요??

Provider 컴포넌트와, utils 폴더에 두고 사용하는 것 둘 다 전공을 참조하고 전공을 변경하기 위한 함수, 변수 의존성을 모든 컴포넌트에 주입해준다다는 공통점이 있다고 생각 되는데요, 차이점은.. 딱히 없다고 생각됩니다. utils 폴더에 해당 로직을 구현했을 때 확실한 장점이 있지 않다면 Provider로 주입하고 훅으로 꺼내서 사용하는 것을 유지하는게 더 괜찮다고 생각 되네요, 왜냐면 useMajor 훅을 사용하고 있는 컴포넌트가 굉장히 많아서 이 훅을 걷어 낸다면 굉장히 많은 코드를 수정해야할 것 같아요(귀찮아요...귀찮다는건 장난입니다..)

[pp449]

전공값 조회/수정을 모두 localStorage 를 이용하는데 Provider 로 굳이 감싸지 않고 Util 로 사용하는건 어떤가요??

Provider 컴포넌트와, utils 폴더에 두고 사용하는 것 둘 다 전공을 참조하고 전공을 변경하기 위한 함수, 변수 의존성을 모든 컴포넌트에 주입해준다다는 공통점이 있다고 생각 되는데요, 차이점은.. 딱히 없다고 생각됩니다. utils 폴더에 해당 로직을 구현했을 때 확실한 장점이 있지 않다면 Provider로 주입하고 훅으로 꺼내서 사용하는 것을 유지하는게 더 괜찮다고 생각 되네요, 왜냐면 useMajor 훅을 사용하고 있는 컴포넌트가 굉장히 많아서 이 훅을 걷어 낸다면 굉장히 많은 코드를 수정해야할 것 같아요(귀찮아요...귀찮다는건 장난입니다..)

학과가 변경되는 경우 리렌더링에 관한 문제는 없을까요??
사실 실제 동작했을때 성능적으로 문제는 없을거 같긴한데, 혹시나 비효율적인 부분이 있는건 짚고 가는것도 좋을거 같아서요

[hwinkr]

전공값 조회/수정을 모두 localStorage 를 이용하는데 Provider 로 굳이 감싸지 않고 Util 로 사용하는건 어떤가요??

Provider 컴포넌트와, utils 폴더에 두고 사용하는 것 둘 다 전공을 참조하고 전공을 변경하기 위한 함수, 변수 의존성을 모든 컴포넌트에 주입해준다다는 공통점이 있다고 생각 되는데요, 차이점은.. 딱히 없다고 생각됩니다. utils 폴더에 해당 로직을 구현했을 때 확실한 장점이 있지 않다면 Provider로 주입하고 훅으로 꺼내서 사용하는 것을 유지하는게 더 괜찮다고 생각 되네요, 왜냐면 useMajor 훅을 사용하고 있는 컴포넌트가 굉장히 많아서 이 훅을 걷어 낸다면 굉장히 많은 코드를 수정해야할 것 같아요(귀찮아요...귀찮다는건 장난입니다..)

학과가 변경되는 경우 리렌더링에 관한 문제는 없을까요?? 사실 실제 동작했을때 성능적으로 문제는 없을거 같긴한데, 혹시나 비효율적인 부분이 있는건 짚고 가는것도 좋을거 같아서요

상태를 사용하지 않기 때문에, 새로고침하지 않는 한 리렌더링은 발생 안하지 않을까요? 리액트에서 컴포넌트가 리렌더링 되는 경우는 리액트 훅으로 관리하는 상태가 변경되었을 때인데, 로컬 스토리지를 사용하기 때문에 리렌더링은 발생 안할 것 같네요. 그리고, 학과가 변경 되었을 때도 정상적으로 동작하는 걸 확인 했습니다 😊

[pp449]

✅ 좋아요~