기본구현 마무리 – 보완점 - 풀스택개발 EastFlag

axios 에러 처리 및 인증 처리

http 호출후 에러가 발생할 수 있다.

http 에러의 경우는 개발자가 try -catch 문으로 잡는다고 해서 걸리지 않는다는 점을 반드시 기억해야 한다. 예를 들어 json 을 받기로 했는데 www-url-form-encoded 형태로 보내게 되면 415 Media Support Error 가 발생하게 되고 이 에러는 웹 서버에서 처리해서 리턴되므로 개발자가 코딩한 try-catch 문까지 오지 않는다. 따라서 클라이언트에서 2xx 번대가 아닌 status 가 올때 어떻게 처리할지 명시해야 한다.
그외의 에러는 try-catch 문에서 걸린다. DB 조회시 DB에서 에러가 발생하거나 할 경우가 그 예이다. 이럴 경우는 상태코드는 5xx 번대로 리턴해서 처리하거나 혹은 2xx을 리턴하고 별도의 에러코드를 정의해서 리턴해도 좋다.

axios 를 호출후 위의 1, 2 번과 같은 에러를 처리하기 위해서 호출시 마다 코드를 넣는것은 너무 중복이다. 이런것들을 일괄적으로 처리하는 방법이 스프링에서는 AOP같은 기법이 있고 자바스크립트 같은 경우는 미들웨어 같은 방법을 사용해서 처리할 수 있다.

axios 에서는 interceptors 라는 미들웨어를 제공해주기 때문에 request 혹은 response 시에 동일한 로직을 수행하도록 해준다. 여기를 참고하자.

// Add a request interceptor
axios.interceptors.request.use(function (config) {
    // Do something before request is sent
    return config;
  }, function (error) {
    // Do something with request error
    return Promise.reject(error);
  });

// Add a response interceptor
axios.interceptors.response.use(function (response) {
    // Any status code that lie within the range of 2xx cause this function to trigger
    // Do something with response data
    return response;
  }, function (error) {
    // Any status codes that falls outside the range of 2xx cause this function to trigger
    // Do something with response error
    return Promise.reject(error);
  });

// Add a request interceptor

axios.interceptors.request.use(function (config) {

// Do something before request is sent

return config;

}, function (error) {

// Do something with request error

return Promise.reject(error);

});

// Add a response interceptor

axios.interceptors.response.use(function (response) {

// Any status code that lie within the range of 2xx cause this function to trigger

// Do something with response data

return response;

}, function (error) {

// Any status codes that falls outside the range of 2xx cause this function to trigger

// Do something with response error

return Promise.reject(error);

});

예를 들어 jwt 인증을 수행하고 토큰을 받아오면 토큰을 request 헤더에 넣어줘야 하는데 매번 넣어줘야 하므로 이런 경우 request interceptor에 넣어준다.

200번대가 아닌 에러가 올 경우 처리는 response interceptors에 에러 처리를 넣어준다.

모달창을 글로벌로 처리

앞에서 게시판 삭제를 할때 모달창을 게시판 상세보기에 넣었다. 그런데 만일 다른 페이지에서도 모달창을 사용할려고 모달창을 또 삽입하게 되면 중복이다. 그러므로 모달창은 최상위 부모 컴포넌트에 한번만 삽입을 하고 redux를 통해서 모달창을 띄우거나 내리도록 처리하는게 바람직한 방법이다.

프로그레시브바 띄우기

특정 페이지에 접근시 http를 호출해서 데이터를 가져오는 경우라면 페이지 진입후 화면이 렌더링 되고 서버에서 데이터를 가져와서 뿌려주기까지 시간이 걸릴수 있다. 이렬 경우 프로그레시브바를 띄워주는게 바람직한데 이것도 모달창과 마찬가지로 글로벌하게 처리해주는게 바람직하다.

루트 컴포넌트에 프로그레시브바 UI를 삽입하고 프로그레시브바를 띄우고 싶은 컴포넌트는 redux 스토어에 데이터를 디스패치 하도록 한다.

인증과 권한

익명 게시판이 아니라면 보톤 게시판이나 댓글은 사용자 테이블과 1:n 관계를 이루게 된다. 서버에서 사용자 테이블과 권한 테이블을 추가하고 REST api도 추가해야 한다.

페이징 방식이라면 RFC6265에 서술된 세션과 쿠키 방식으로 인증을 하게 된다. 세션은 서버에 저장된 값이고 클라이언트는 세션에 어떤 값이 저장되어있는지 알 수가 없다. 만일 리액트같은 클라이언트 렌더링 방식이 세션 방식을 사용하게 된다면 매번 세션값을 조회해야하는 불편함이 있으므로 적합하지 않다. 그래서 클라이언트 사이드 렌더링에서는 RFC7519 jwt 인증을 사용하는것이 바람직하다.

angualr 나 vue 같은 경우는 rotuer에 이런 기능들이 포함되어있으나 react는 이런 기능이 없다. 그래서 별도로 구현해줘야 한다.

라우팅 추가 구현 사항

상단 공통 메뉴는 구현하지 않았는데 상단 메뉴를 구현하거나 네스티드 라아퉁일 경우는 추가적으로 좌측 메뉴 혹은 우측 메뉴를 추가할수도 있다.

네스티드 라우팅이란 특정 유알엘이 라우팅을 다시 포함하는 경우이다. 예를 들어, 상단에 회원관리라는 메뉴를 클릭했다면 좌측에 회원 등록, 회원 목록보기, 회원 수정과 같은 추가적인 메뉴가 좌측 메뉴에 나타나고 좌측 메뉴를 클릭시 우측 영역이 라우팅 되도록 만들면 이것이 네스티드 라우팅이 된다.

네스티드 라우팅의 또다른 예는 게시판 목록을 보다가 상세보기를 클릭하면 화면이 완전이 전환되어서 상세보기로 이동하는것이 아니라 게시판 목록은 바로 아래에 있고 상세화면이 목록 바로 위에 나타나도록 하면 이것도 네스티드 라우팅으로 구현할 수 있다. 이렇게 구현하는것이 redux pub-sub 도 활용해야 해서 조금 더 까다롭다.

Advanced 컴포넌트

프로그램의 완성도를 높이기 위한 컴포넌트들은 많이 생략하였다.

게시판 목록보기의 경우 페이지네이션이 필요한데 react-bootstrap에서는 페이지네이션 컴포넌트를 제공하지 않기 때문에 별도의 라이브러리를 설치해야 한다.

등록, 수정, 삭제 버튼을 클릭후 그 결과를 알려주기 위해서 스낵바나 토스트 같은 UI를 사용하는데 react-bootstrap에서는 토스트가 다음과 같이 있긴한데, UI가 너무 허접하다. 별도의 외부 라이브러리를 설치하는게 더 좋을거 같다.

게시판 내용을 작성할 때 textarea라는 html 기본 폼을 사용하였는데, html editor를 사용하는게 바람직하다. 이것을 구현하는것은 사실 너무 어려우므로 보통 3rd party 라이브러리를 사용한다. react, vue, angular 공통으로 가장 많이 사용하는 html editor는 ckeditor이다.

Go to top

디테일한 구현 사항들은 clone 코딩을 참고하자.