본문 바로가기
WIL

[WIL] 개발일지: 항해99 10주차(실전프로젝트)

by 0sae 2021. 5. 10.

5월 둘째 주: 항해99 10주차

Chapter 6: 실전프로젝트(2주차) 'Sflash(스플레쉬)'

네이버/카카오/구글 소셜로그인 구현하기

- 소셜로그인은 백엔드에서 탄탄하게 준비해 주셔서 로그인 기능 자체에서는 크게 어려움은 없었지만 몇몇 변수를 해결해야 했다.

1.  url 에서 값 가져오기

프론트 단에서는 백에서 전달해 준 링크로 연결해주면 url에 token 정보와 nickname 정보를 전달해 주었다. 여기서 url로부터 정보를 받아오는 방식은 처음으로 구현해 보았다.

 

2. 소셜로그인 사용자에게도 고유의 nickname 부여하기

이 때 겪은 어려움은 원래 nickname은 일반로그인에서 중복확인을 거쳐 받아오게 되는데, 소셜로그인 시에는 서비스에서 사용할 고유한 nickname을 설정할 수 없다는 것이었다. 이 점은 소셜 로그인시 백에서 'sflash12345' 와 같이 랜덤 닉네임을 부여하고 사용자는 유저 페이지의 프로필 편집에서 닉네임을 수정할 수 있도록 해 문제를 해결했다.

 

3. 일반 로그인과 소셜로그인의 이메일이 같을 때 

(1) 일반 회원가입으로 가입한 사람이  같은 이메일로 소셜로그인을 이용하려고 할 때 

(2) 소셜로그인으로 가입한 사람이 일반 로그인을 시도할 때 

(3) 소셜로그인으로 가입한 사람도 일반로그인 사용자처럼 유저정보가 DB에 저장되고 임의의 비밀번호가 부여되도록 했다.

유저 스토리 페이지 

1. API 관리하기 

API 설계단에서 유저스토리의 API를 어떤 방식으로 받을 건지에 대해 고민이 많았다. 스토리 페이지는 크게 3가지 내용으로 나뉜다. 

(1) 상단의 유저정보(닉네임, 프로필이미지, 자개소개)

(2) 유저가 올린 게시물

(3) 유저가 좋아요한 게시물

이때, 유저가 올린 게시물과 좋아요한 게시물에 대한 API는 따로 받기로 했고, 유저의 정보를 두개의 API 에 담아서 받을 것인지 or 유저정보 API를 따로 받을 것인지 였다. 처음 결정은 모두 담아서 받기로 했다. 하지만 정작 API를 받고 연결하려고 하니 여러개의 list안에 각각 담겨져있는 유저정보를 빼와서 사용하는 것 자체가 비효율적이어 보였고, 가장 큰 문제는 게시물이 없을 때 였다. 데이터 length가 0 이기 떄문에 undefined 뜨는 문제가 있었다. 결국 API를 3개로 각각 나누어 받으니 위에 문제도 해결하고 데이터를 관리하기도 훨씬 용이했다.

 

2. 이중 탭 기능 활용하기

해당 서비스의 유저 스토리 페이지에서는 아래와 같이 2개의 탭 기능이 존재한다.

(1) '유저가 올린 게시물/유저가 좋아요한 게시물'을 나누는 탭

(2) (1) 내용을 '리스트/지도' 형태로 보여주는 탭

두개의 탭을 어떻게 코드를 짜야 효율적일지에 대해 많은 고민이 있었다. 먼저 데이터를 기준으로 우선순위를 정했다. 그러면 (1)의 각각의 데이터를 (2)의 동일한 구조에 넣어 적용시키면 된다고 생각했기 때문이다.

이를 해결하기 위해 Story.js 페이지에 (1)의 탭 코드를 넣고 탭의  StoryContent.js 컴포넌트부분에 (2)의 탭기능 코드를 넣어 데이터가 바뀔때마다 같은 (2)에 데이터 값만 바뀌어 활용할수 있도록 하니 코드가 훨씬 깔끔해졌다.

 

3. 내 스토리를 다른 사용자도 볼 수 있도록 하기

처음에는 '내스토리 = 마이페이지' 라고 생각해서 get API 요청할 때 헤더에 jwt토큰을 담아서 요청하는 식으로 했다. 페이지를 만들 때는 로그인한 사용자 기준으로 화면을 만드니 문제를 느끼지 못했는데, 곰곰히 생각해보니 토큰을 보내야 데이터를 받아볼 수 있다는 것은 다른 사람들은 내 스토리 페이지를 볼 수 없다는 것이었다...!!  처음에는 멘붕이었는데 다시 생각해보니 토큰을 보내지 않고도 데이터를 받아올 수 있도록하면 간단하게 해결되는 문제였다. 이 부분은 차주에 수정할 예정이다.

마무리 및 차주 계획

우리의 프로젝트는 짠것도 아닌데 프론트엔드 3명이 사이좋게 나누어 작업할 수 있도록 세가지 파트로 나뉜다. 카테고리를 기준으로 게시물을 보여주는 (1)map과 (2)postlist, 그리고 (3)user 부분이다. 제비뽑기로 그 중 나는 user 부분을 담당하게 되었고 user부분의 메인인 로그인/회원가입은 가장 먼저 구현해야하는 부분이기 때문에 첫주가 조금 빡세고 후반부는 여유가 있어 다른 분들을 도와드릴 수 있을 줄 알았는데 이전 프로젝트에서는 내가 했던 user기능은 매우 허술했었구나라는 생각이 들정도로 생각할수록 고려해야할 부분이 많았다.

 

나의 페이지 이지만 남들도 볼수 있도록 해야 하는 경우에가 더욱이 그러했다. 유저가 처음 회원가입을 했을 때(post_list.length=일 때) 보여지는 화면도 고려해야했고, 소셜로그인의 변수들도 생각보다 많았다. jwt 가 만료되었을 때 화면에서 후처리는 어떻게 할 것이며, 유저 정보를 바꿀 때에도 confirm도 더 신경써야했다. 그러다보니 할수록 기획할 때 생각지도 못했던 기능들이 늘어났다... 청므 user파트를 담당하게 되었을 때는 서비스의 메인기능을 하지 못하는 것에 대한 아쉬움이 없지 않아 있었는데 모든 서비스의 기본이 되는 user 기능에 대해 깊게 고민하고 배우고있는 것 같아 user를 담당하기를 잘했다는 생각이 든다.

 

차주는

(1) 디자인 입히기

(2) 유저페이지 보완하기(API 수정, 비동기처리)

(3) 문의하기 페이지

(4) 배포해보기(그래야 소셜로그인에 후처리도 해볼 수 있다고 백엔드 분께서 그러셨다 !!)

(5) 마케팅 계획 세우기

를 진행할 계획이다.

 

산은 하나 넘은듯 하지만 차주 역시 바쁜 한주가 될 것 같다. 그러고 나면 더 큰 산이 기다리고 있을 것 같다.

다음주도 어김없이 홧탱이다 !!!!!!!!!!+_+