3차 데모데이 피드백과 반영

3차 데모데이를 진행했다.

저번 데모데이와 마찬가지로 진행상황과 앞으로의 계획,

그리고 주어진 요구사항에 대해 발표하였다.

 

 

공통 진행

저번 피드백에 따라 백엔드와 프론트엔드의 싱크를 맞추기 위해 노력했다.

각 기능을 정리하고 어느 데모데이까지 마칠 것인지 작성하고

백엔드와 프론트엔드 나누어 각자 진행 상황을 표시하였다.

 

둘 다 한 기능에 대한 개발이 완료가 되면 이슈를 열고 확인하는 방식으로 진행하였다.

 

 

리뷰 작성과 이미지 업로드 기능 구현

사용자들이 편의점 리뷰를 작성하는 기능을 구현하면서

이미지 업로드를 할 수 있도록 했다.

FormData를 통해 EC2로 직접 이미지를 보낼 수 있도록 하였다.

 

이 과정에서 이미지는 바이너리 형식, 다른 부분은 json 형식이라

이를 한 번에 묶어 보내는 과정에서 많은 어려움을 겪었다.

 

Blob 객체를 사용해 서버에 보내는 방식을 채택하였고

성공적으로 POST 요청을 할 수 있었다.

 

자세한 내용은 여기로

 

 

무한 스크롤 구현

페이징 하는 방식을 무한 스크롤로 결정하고 이를 구현하였다.

모바일 기준의 서비스이기 때문에 약 7000개의 상품 데이터를 끊김 없이 보려면

무한 스크롤 방식이 적합하다고 생각하였다.

 

상품 목록에서 무한 스크롤이 발생하는데 

여기서 상품 카테고리를 바꾸면 해당 페이지를 0으로 초기화를 한 후 요청을 보내야 한다.

그런데 이 과정에서 초기화와 비동기 요청의 순서를 보장할 수 없는 문제가 생겼다.

 

이를 해결하기 위해 previousCategoryId를 ref로 값을 저장했고

그 후 categoryId와 비교해 값이 바뀌었다면 page를 초기화한 후 비동기 요청을 보내도록 수정하였다.

 

 

로그인 구현

카카오 OAuth를 이용해 로그인을 구현하였다.

 

로그인 과정을 거치고 카카오가 사용자 정보를 제공하면,

서버는 사용자를 식별하기 위한 쿠키 값을 반환한다.

이 쿠키 값을 바탕으로 클라이언트는 기존 회원이나 신규 회원이냐에 따라 각각 다른 곳으로 리다이렉트 시킨다.

그다음 클라이언트는 받은 쿠키 값과 함께 사용자 정보 조회를 요청하고,

서버는 받은 사용자 정보를 클라이언트에 보내주는 과정으로 로그인이 진행된다.

 

로그인에서는 두 가지 문제가 발생하였다.

 

먼저, AuthPage에서 세션 아이디 요청을 보냈을 때 브라우저에 쿠키가 저장되지 않았다.

이는 fetch API에서 credentials 옵션의 기본값을 omit으로 설정해 발생한 문제였다.

요청에 담을 뿐만 아니라 응답으로 오는 쿠키를 브라우저에 저장하기 위해서 include로 설정하였다.

수정 후 정상적으로 쿠키가 저장되는 것을 확인할 수 있었다.

 

둘째, 세션 아이디가 만료되었어도 로컬 스토리지에 멤버가 저장되어 있어 로그인을 할 수 없는 문제가 있었다.

이는 마이페이지로 접속할 때 멤버 조회 요청을 하는 방식으로 수정해 해결하였다.

로그인 에러가 발생하면 현재 저장되어 있는 멤버 값을 초기화하고 로그인 페이지로 리다이렉트 시켰다.

다른 세션 아이디가 필요한 요청에서도 로그인 에러가 발생한다면 위와 같은 방식으로 에러처리를 했다.

 

 

웹 표준과 웹 접근성 고려

웹 표준을 지키기 위해 노력했다.

 

ios 모바일 브라우저와 사파리 데스크톱 브라우저에서 특정 dialog가 안 뜨는 오류가 있었다.

브라우저 css 스타일이 통일되지 않는 것이 문제였다.

스타일 수정을 통해 모든 브라우저에서 동일한 콘텐츠를 볼 수 있도록 구현하였다.

 

웹 접근성을 지키기 위해 노력했다.

 

먼저, 키보드만으로 리뷰 작성이 가능하도록 구현하였다.
또한, 코드 리뷰를 통해 서로 웹 접근성을 지키고 있는지 확인하였다.

 

특히 가장 많이 논의했던 부분은 div를 감싸고 있는 태그를 button으로 해야 할지 a 태그로 해야 할 지에 대한 부분이었다.

원래는 item 컴포넌트라 button으로 구현하였는데

어딘가로 이동하는 건데 button 태그를 쓰는 게 맞는 것인가 생각이 들었다.

그렇다고 a 태그로 고친다고 해도 그 안에 block 요소가 들어가도 되는 것인지에 확신이 없었다.

 

우리끼리 논의도 많이 하고 코치님께 여쭈어도 보고 공부도 한 결과

기능과 접근성적인 측면에서 a 태그를 사용하는 것이 맞다는 결론이 나왔다.

 

처음에는 스크린 리더와 같은 보조 기술 사용자가 웹 페이지를 쉽게 이해할 수 있도록 하자는 목적을 가지고 진행했는데 

그 과정에서 개발자인 우리 또한 웹 페이지 구조를 쉽게 파악할 수 있어 좋았다.

 

 

피드백

3차 데모데이에서는 아래와 같은 피드백을 받았다.

 

1. 구현이 되지 않은 기능을 노출시키는 것은 의미가 없다.

내비게이션 바를 보면 구현되지 않은 꿀조합 탭이 있는 것을 볼 수 있다.

애초에 구현할 때 미리 만들 것을 생각해 만들어두지 말고,

구현 당시 넣는 방식으로 구현하도록 하자.

 

2. 상품 데이터를 채우는 것보다 리뷰를 채우는 것에 더 집중하는 것은 어떨까?

7000개 정도의 데이터를 채웠는데 사용자가 이 모든 데이터를 다 이용하지는 않을 것 같다.

서비스의 핵심이 리뷰 공유이니까 차라리 리뷰 개수를 채우는 것이 힘을 쏟는 것이 더 맞아 보인다.

사용자로 하여금 등록되지 않은 상품을 우리에게 요청할 수 있는 창구를 만드는 것은 어떨까?

 

3. 메인 페이지를 잘 활용하자.

메인 화면은 모든 사용자가 처음 접근하는 페이지이다.

비싼 자리이기 때문에 어떻게 활용하는 것이 효과적일지 생각해 보자.

 

4. 리뷰 이미지 꼭 필요한가?

지금 리뷰 이미지가 대체 이미지를 사용하고 있는데 이럴 거면 굳이 리뷰 이미지가 필요한가?

 

 

위 피드백에 대한 해결 방법은 아래와 같다.

 

 

1. 구현이 되지 않은 기능을 노출시키는 것은 의미가 없다.

나중에 꿀조합이 무조건 추가될 예정이니까 기능이 없는데도 내비게이션 파일에 넣었다.

최소 해당 탭을 눌렀을 때 준비 중이라는 문구라도 띄워야 했는데

그냥 아무것도 없는 흰 배경을 띄웠다.

 

다음 구현에 꿀조합을 구현할 예정이라 다시 없앨 필요는 없지만

앞으로는 구현되지 않은 기능은 미리 추가하지 않도록 해야겠다.

 

2. 상품 데이터를 채우는 것보다 리뷰를 채우는 것에 더 집중하는 것은 어떨까?

편의점 음식은 계속해서 새로 나오기 때문에 우리가 매번 알아내기 쉽지 않을 것 같다.

그리고 모든 새로운 음식을 추가한다고 하더라도 그걸 사용자가 사용하지 않는다면 의미가 없다.

 

따라서 피드백대로 사용자가 우리에게 요구할 수 있도록 창구를 만드는 것이 좋을 것이라 생각했다.

따라서 채널톡을 도입하기로 했다.

 

3. 메인 페이지를 잘 활용하자.

메인 페이지의 경우 고민이 많다.

어떻게 해야 사용자가 우리 서비스를 한눈에 이해하고 다음 동작을 유도할 수 있을지 생각해 보아야겠다.

비슷한 리뷰 서비스가 있다면 그 서비스를 참고해 보면 좋을 것 같다.

 

4. 리뷰 이미지 꼭 필요한가?

우리 서비스의 경우 상품 사진이 저작권에 걸릴 수 있기 때문에 함부로 사용할 수 없다.

따라서 해당 상품의 리뷰 중 가장 좋아요를 많이 받은 리뷰의 사진으로 대체하기로 했다.

아직 리뷰가 많지 않기 때문에 대체 이미지가 나타나는 것은 당연한 일이다.

리뷰 사진으로 바뀌면 더 다채로운 리뷰가 되지 않을까 생각한다.