[알리미 1] 리팩터링 전, 추가할 사항들을 정리해보자.

axios intercepter 관련 docs와 아티클을 보고 정리 및 학습하려다가
다른 사람들은 login과 auth를 전반적으로 어떻게들 관리하는지, 내가 맞게 하고 있는 건지 궁금해서 여러 글들과 영상을 찾아보다가 해당 영상을 발견하였다.
해당 영상을 토대로 내 프로젝트에 어떤 것을 보완해야 하고, 어떤 것들을 수정하면 좋을지 생각해보자.

---

https://www.youtube.com/watch?v=brcHK3P6ChQ 

• state와 useEffect를 너무 많이 선언했는데 괜찮은가?
  reactForm 라이브러리를 사용한다면 더욱 효과적일까?
• 스크린리더를 적용해서 접근성을 높였다.
  제로베이스 미션 1 과제에서 css미션 할 때 사용해본 적이 있는데, jsx에서 사용되는 거는 처음 봐서 인상 깊었고,
  나도 적용해보고 싶다고 생각했음
  이 영상을 보고 구글 크롬에 screen leader 확장 프로그램이 있다는 것을 처음 알았음! 다운로드하여서 적용해보자.
  https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label
  https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live
  https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-describedby
• 회원가입이 성공적으로 완료되면 sign in 하라고 다른 화면을 푸시해줌.
  나는 기존의 화면에 alert를 주로 사용해왔었는데, 이러한 방식도 괜찮을 것 같다는 생각이 들음.
  가입을 완료하면 바로 sign in 컴포넌트 쪽으로 푸시하는 방법을 고려해봐야겠음.
• 현재 내 프로젝트는 input의 type만을 활용해서 진짜 기본적인 조건만 검사하고 있는데,
  정규식을 사용해서 유효성 검사를 조금 더 철저히 해보자.
• api 폴더와 axios를 적용하는 코드 부분, 폴더 구조 재구성하고 코드 수정.
• error handlering : 각각의 err.response에 따른 반응 추가.

 

---

https://www.youtube.com/watch?v=X3qyxo_UTR4 

• 해당 영상에서는 성공적인 로그인 후 서버로부터 받아오는 accessToken를 콘텍스트 api로 전역 상태 관리하는데,
  아직 콘텍스트 api 관련 강의를 한번 정도만 들어보고 막상 실습에 적용해본 적은 없기 때문에,
  이번 기회에 나도 콘텍스트 api를 사용해보고 후에 recoil로 변경해보면 좋을 것 같음.

import { createContext, useState } from "react";

const AuthContext = createContext({});

export const AuthProvider = ({ children }) => {
  const [auth, setAuth] = useState({});
  
  return (
    <AuthContext.Provider value={{ auth, setAuth }}>
      {children}
    </AuthContext.Provider>
  )
}

export default AuthContext;

 

---

https://www.youtube.com/watch?v=oUZjO00NkhY

ReactDOM.render(
  <React.StrictMode>
    <BrowserRouter>
      <AuthProvider>
        <Routes>
          <Route path="/" element={<App />} />
        </Routes>
      </AuthProvider>
    </BrowserRouter>
  </React.StrictMode>
)

const App = () => {
  return (
    <Routes>
      <Route path="/" element={<Layout />}>
        <Route path="login" element={<Login />} />
        <Route path="register" element={<Register />} />
        <Route path="linkpage" element={<Linkpage />} />
        
        <Route path="/" element={<Home />} />
        <Route path="editor" element={<Editor />} />
        <Route path="admin" element={<Admin />} />
      </Route>
    </Routes>
  )
}

const Layout = () => {
  return (
    <main className="App">
      <Outlet />
    </main>
  )
}

• 해당 영상에서는 index.js에 context API, router-dom을 적용해주고,
  App 컴포넌트에서 Layout 컴포넌트를 Route로 받아오고, Layout 안에서 outlet으로 나머지 하위 컴포넌트를 적용하는 방식으로 코딩하였다.
  내가 기존에 구현했던 App컴포넌트에서 nested Route들을 보여주는 것이 더 가시적 일지,
  해당 방법이 더 나에게 괜찮을지 아직까지는 명확하게 판단할 수 없는 것 같지만, 아무래도 Layout을 필요로 하는 프로젝트라면 해당 영상의 방법이 더 괜찮을 것 같다는 생각이다.
  내가 리팩터링 하려는 프로젝트는 전체적으로 스타일링하는 Layout이 없어서 기존의 방법을 사용할 것 같다.
• 나는 token이 없을 경우 react-router로 처리해주는 로직을 App컴포넌트에서 바로 구현했는데,
  이 영상에서는 file을 하나 생성해서 그 안에서 처리를 해주고, 그것을 App컴포넌트에 import 해서 필요한 Route들을 래핑 해주는 방법으로 사용하고 있다.
  나는 token이 있을 경우와 없을 경우에 삼항 연산자를 통해 navigate 처리해주었다. 그리고 생성한 페이지가 많지 않아서 아직까지는 굳이 별도의 file을 만들지 않아도 될 것 같은데, page가 늘어날 경우에는 해당 영상처럼 사용하는 것도 좋아 보인다.

import { useLocation, Navigate, Outlet } from "react-router-dom";
import useAuth from "../hooks/useAuth";

const RequireAuth = () => {
  const { auth } = useAuth();
  const location = userLocation();
  
  return (
    auth?.user
    	? <Outlet />
        : <Navigate to="/login" state={{ from: location }} replace />
  )
}

• 나도 authorization을 이용하여 이용자에 따라 각 페이지마다 권한을 부여하는 것을 구현해보면 좋겠다는 생각이다. 
  현재는 todo-list이기 때문에 user, admin정도의 권한을 생성하면 좋을 것 같음.
  내가 서버에 다른 기능을 추가할 수는 없을 것 같기에 user는 todo-list를 삭제할 수 없고, admin만이 삭제를 할 수 있도록 만들어야 할 것 같다.

---

https://www.youtube.com/watch?v=nI8PYZNFtac 

• JWT : JSON Web Tokens
  • Access Token : Short Time 
    • Sent as JSON Client stores in memory. Do Not store in local storage or cookie
    • Issued at Authorization Client uses for API Access until expires
      Verified with Middleware New token issued at Refresh request
  • Refresh Token : Long Time
    
    • Sent as httpOnly cookie. Not accessible via JavaScript. Must have expiry at some point
    • Issued at Authorization Client uses to request new Access Token.
      Verified with endpoint & database Must be allowed to expire or logout
• 아마도 저 영상에 따르면 현업에서 사용하는 방식은 JWT를 local 또는 cookie에 넣지 않고,
  짧은 시간 동안 유지되는(ex. 10-15분) AccessToken과 비교적 오래 유지되는 (ex. 하루) RefreshToken을 서버로부터 전달받아야 한다.
  또한 AccessToken이 만료되더라도 아직 RefreshToken이 존재한다면 다시 재발급을 받을 수 있고,
  AccessToken과 RefreshToken 모두 만료될 경우에 강제 logout 되어 다시 login 해야 한다.
  보통 AccessToken으로 API를 처리하고, Refresh Token은 AccessToken을 새로 발급받기 위한 수단인 셈.
• 내 프로젝트는 과제였기에 빠른 기간 내에 구현해야 하는 느낌이었어서, AccessToken을 localStorage에 넣어 간편하게 사용을 하였는데 사실 token 같은 부분이 보안에 직결되어있어서 실전에서는 더욱 고민하고 신경 써서 다뤄야 할 것 같다.
• 해당 영상에서는 많이 이해 못 한 부분들이 많다.
  axios intercepter도 처음 배워보는 것이고, token도 이런 식으로 깊게 다뤄본 적이 없어서 여러모로 어려운 영상이었음.
  코드도 보고 영상도 두 번 세 번 보면서 차근차근 이해하여야 할 것 같음.
  현재 내 프로젝트에서 적용할 수 있는 부분은 나도 현재 token을 다루는 코드를 hooks로 빼놓긴 했는데,
  그 부분을 다시 점검해보아야 할 것 같고, interceptor를 적용할 수 있는지에 대해 고민해보아야겠다.

---