거니의 velog

3. 엔티티 처리* 파일 업로드의 특징은 파일 자체가 부수적인 요소라는 점이다. 예를 들어, 상품 등록의 경우 핵심은 상품 자체이고 파일들은 이를 설명하는 부수적인 데이터이다. 이럴 때 상품은 고유한 PK를 가지는 하나의 온전한 엔티티로 봐야 하고 파일들은 엔티티에 속해 있는 데이터로 봐야 한다. * JPA에서는 '값 타입 객체'라는 표현을 쓰는데 컬렉션으로 처리할 때는 @ElementCollection을 활용한다. 값 타입 객체는 엔티티와 달리 PK가 없는 데이터이다. 예제에서 하나의 상품 데이터는 여러 개의 상품 이미지를 갖는 1:N 관계이다. * domain 패키지에 Product 엔티티 클래스와 ProductImage 클래스를 추가한다.* ProductImage는 @Embeddable 어노테이션을..

* 간단한 Todo 예제로 프로젝트의 기본 구성을 경험했다면 이제는 조금 주의해야 하는 데이터를 다룰 것이다. 이번 장에서는 첨부파일이 여러 개 포함되는 상품 데이터를 예제로 다룬다. 상품 데이터는 첨부파일을 같이 처리하기 때문에 썸네일 이미지의 생성이나 데이터의 구조가 기존과 달라지게 된다. * 이번 장의 개발 목표는 다음과 같다. (1) 파일 업로드와 다운로드 처리 (2) 하나의 상품에 여러 이미지를 가지는 데이터 처리 (3) 첨부파일이 있는 API 개발과 테스트 1. 파일 업로드를 위한 설정 * 파일 업로드에 필요한 모든 기능은 이미 스프링 Web 관련 라이브러리에 존재하므로 프로젝트의 application.properties에는 이와 관련된 설정을 추가한다. * 예제에서는 프로젝트의 실행 폴더에 ..

7. 수정/삭제 처리 * 수정/삭제 화면은 기존의 ModifyPage와 새롭게 작성할 ModifyComponent를 이용해서 처리한다. 코드를 구현하기 전에 수정/삭제 후에는 어떤 식으로 동작해야 하는지를 정리해 본다. - 삭제(Delete 버튼) : 삭제 결과를 모달창으로 보여주고 '/todo/list'로 이동 - 수정(Modify 버튼) : 수정 결과를 모달창으로 보여주고 '/todo/read/번호'로 이동 * 수정/삭제 기능 모두 서버의 호출 결과를 이용해서 모달창을 보여주는 점은 공통적이고 이후의 이동 경로에서 차이가 난다. (1) 수정/삭제 호출 기능 작성 * api/todoApi.js에는 수정과 삭제에 필요한 함수들을 추가한다. import axios from "axios"; export co..

6. 등록 컴포넌트와 모달창 처리 * 지금껏 작성한 조회나 목록 기능과 달리 남은 기능들은 다음과 같은 공통점이 있다. - GET 방식이 아니라 POST/PUT/DELETE와 같이 다른 방식으로 호출 - API 서버 호출의 결과가 주로 성공/실패와 같은 단순한 결과 - 처리 후 다른 경로로 이동하는 경우가 많음(리다이렉트) * 과거의 서버사이드 프로그래밍은 서버에서 처리한 후에 결과 메시지를 모두 만들어서 전송하거나 PRG(Post-Redirect-Get) 방식으로 다른 경로를 호출하는 방식이었다. 리액트와 같은 애플리케이션에서는 기본적으로 모든 처리는 현재 화면을 중심으로 처리된다. 현재 화면에서 서버를 호출하고 결과 역시 현재 화면에서 처리하고 이후에 이동하는 방식이다. * 등록 처리는 입력하는 화면..

5. 목록 데이터 처리 * 조회는 단순하게 서버의 데이터를 보여주는 기능만으로 구현할 수 있지만, 목록 데이터는 페이지 처리나 여러 링크 등이 추가되어서 더 복잡한 구성을 하게 된다. 가장 먼저 구현할 기능은 브라우저 경로에 있는 쿼리스트링으로 페이지 번호/사이즈에 따라서 서버를 호출하고 결과를 출력하는 것이다. (1) 목록 데이터 가져오기 * 해당 데이터를 가져오는 기능은 useEffect()를 사용해서 구현하는 것으로 컴포넌트는 components/todo 폴더 내에 ListComponent로 작성한다. * ListComponent는 useCustomMove()를 이용해서 현재 경로의 page와 size를 구성하고 API 서버를 호출한다. 서버의 데이터는 dtoList라는 배열 데이터와 pageNum..

4. 네비게이션 관련 커스텀 훅 * ReadComponent가 완성되기 위해서 남은 작업은 다시 목록 화면으로 이동하는 기능이 추가되어야 한다. 리액트에서 화면의 구성은 컴포넌트를 이용해서 처리할 수 있지만, 컴포넌트들 내부에서 만들어지는 공통적인 코드의 경우 커스텀 훅(custom hook)을 이용해서 작성한다. * 예제의 경우 조회 화면에서는 다시 목록 화면으로 이동해야 하는 기능이 필요하고 이를 구현하기 위해서 useNavigate()나 useSearchParams를 이용해야만 한다. 이렇게 만들어진 기능은 등록이나 수정/삭제 화면에서도 동일하게 사용된다. (1) 목록 페이지로 이동 * 커스텀 훅을 제작하기 위해서 프로젝트의 src 폴더에 hooks 폴더를 추가하고 useCustomMove.js 파..

* 대부분의 프론트엔드 관련 기술들은 서버와의 비동기 통신을 포함한다. 리액트 역시 Ajax로 서버의 데이터를 이용해서 필요한 기능을 완성한다. 이번 장은 이전에 구성한 서버를 이용해서 Todo의 기능을 완성해 보자. * 이번 장의 개발 목표는 다음과 같다. (1) Axios 라이브러리를 이용한 서버와의 통신 (2) useEffect()를 활용한 비동기 처리와 상태 변경 (3) 커스텀 훅을 이용한 공통 코드 재사용하기 (4) 컴포넌트에서 모달창을 이용해서 결과 보여주기 1. 개발 목표의 이해 * React-Router로 브라우저의 주소창을 처리했고, 스프링 부트로 서버사이드에서 원하는 데이터를 처리할 수 있게 되었다면 이제 각 화면 내부에 필요한 컴포넌트들을 추가해서 실제 내용을 구현해 본다. * 목록 ..

6. @RestControllerAdvice * API 서버는 화면이 없는 상태에서 개발되기 때문에 잘못된 파라미터 등으로 인한 서버 내부의 예외 처리를 @RestControllerAdvice로 처리해 주는 것이 안전하다. * 예를 들어 존재하지 않는 번호의 Todo를 조회하면 NoSuchElementException 에러가 발생한다. - http://localhost:8080/api/todo/33 * 또한 페이지 번호를 숫자가 아닌 문자로 전달하면 MethodArgumentNotValidException 에러가 발생한다. - http://localhost:8080/api/todo/list?page=A&size=10 * 이러한 예외를 처리하기 위해서 controller 패키지 내에서 advice 패키지를..

5. 목록 처리와 DTO* 페이징 처리가 되는 목록 데이터는 크게 1) 해당 페이지의 TodoDTO 리스트 2) 페이지 번호, 전체 데이터의 수, 이전/다음 페이지 처리에 필요한 부가적인 데이터 로 구성될 수 있다. * 부가적인 데이터를 리액트와 같은 프론트엔드 쪽에서 처리할 수도 있지만 서버에서 데이터의 가공이 많을수록 리액트에서 작업이 편해진다. * TodoRepository에서 목록 데이터는 Spring Data JPA 관련된 API들을 이용하기 때문에 Pageable 타입의 파라미터를 사용하고 리턴 타입 역시 Page의 형태로 결과를 생성해 낸다. 엔티티와 그에 관련된 처리는 가능하면 최소한의 영역에서만 처리하고 나머지는 DTO를 이용하는 것이 안전하기 때문에 TodoRepository의 Page..