20240404 (목) 최종 프로젝트 티켓레이더 6주차 - 피드백 수용

1. createdAt, updatedAt 의 LocalDateTime.now() 문제

문제 : 시간이 대한민국/서울 시간과 달라서 리뷰, 티켓 생성 시간 등의 시간이 다르게 나타났음

변경 전

변경 후

 

2. 좋아요 새로고침

 

직접 값 업데이트

 

장점:

빠른 사용자 경험(UX): 서버로부터 응답을 기다리지 않고 즉시 UI를 업데이트할 수 있다. 이는 더 빠르고 반응적인 사용자 경험을 제공

네트워크 트래픽 감소: 서버에 추가 요청을 보내지 않으므로 네트워크 부하가 줄어든다.

단점:

데이터 불일치의 가능성: 동시에 여러 사용자가 같은 이벤트에 좋아요를 누르는 경우, 실제 likeCount와 프론트엔드에서 보여지는 값 사이에 차이가 발생할 수 있다.

오류 처리 복잡성: 좋아요 요청이 실패했을 때 UI를 다시 롤백하는 로직을 구현해야 할 수 있다.

 

서버로부터 값 재요청

 

장점:

데이터 일관성: 좋아요 요청 후 서버로부터 최신 likeCount를 받아와서 표시함으로써, 항상 DB와 일치하는 값을 유지할 수 있다.

간단한 오류 처리: 요청이 실패한 경우 UI를 업데이트할 필요가 없으므로 처리가 더 간단해진다.

단점:

지연된 사용자 경험: 서버로부터 응답을 받아와야 하므로 UI 업데이트가 지연된다.

증가된 네트워크 트래픽: 매번 서버로부터 최신 데이터를 받아와야 하므로 네트워크 부하가 증가한다.

 

결론

두 방법 중 어느 것이 "더 나은" 선택인지는 애플리케이션의 특성과 요구 사항에 따라 다르다. 데이터 일관성이 매우 중요하고 동시에 여러 사용자가 작업을 수행할 가능성이 높은 경우, 서버로부터 최신 데이터를 재요청하는 방식을 선호할 수 있다. 반면, 사용자 경험을 최우선으로 하고 약간의 데이터 불일치가 허용될 수 있는 상황이라면, 직접 값을 업데이트하는 방식이 더 나을 수 있다.

 

1번 방법으로 적용하고자 했으나 버튼을 연속적으로 누르면 누른만큼 숫자가 증가하는것을 확인(물론 실제 DB에 그값이 저장되는것은 아님) 따라서 일단 롤백.. 이부부은 조금더 공부후에 적용시키는 걸로 결정.

 

종종, 이 두 접근 방식의 장점을 조합하기 위해 옵티미스틱 UI 업데이트(즉시 UI 업데이트 후, 백그라운드에서 실제 요청 처리)와 같은 전략을 사용하기도 한다. 이 방법은 사용자에게 빠른 피드백을 제공하면서도, 서버와의 동기화를 유지할 수 있도록 해준다.

 

3. 검색 디폴트 값 설정

 

검색 디폴트값이 없어서 불편해하는 유저가 발생

변경 전

변경 후

4. 선택한 카테고리 하이라이트 기능

 

조금더 직관적이게 선택한 카테고리를 표시해줬음

변경 전

 

변경 후

5. 포스터 클릭시에도 이벤트 상세페이지로 이동

단순하게 이미지에 클릭시 함수를 호출하도록 함

1. 1.