오프라인에서 만드는 우리들의 이야기 - OffStory 최종회고

조주영·2021년 11월 8일
0

데브코스-TIL

목록 보기
34/34

📁프로젝트 소개

📌프로젝트 개요


📌 기술스택

📌 진행방식

🎈배포주소

https://offstory.netlify.app/

💦문제 해결 과정

내가 맡은 페이지 중 문제와 해결과정

🟢 전부 해결
🟡 일부분 해결/리팩토링 필요
🔴 해결 못함

🟢로그인 페이지

⛔새로고침시 로그인 상태가 유지가 안된다.

  • ✅로그인 상태유지를 위해 쿠키를이용->나중에는 세션스토리지를 이용
    -> 🤷‍♂️왜? 개인정보는 세션스토리지를 이용하여 브라우저를 나갈시 자동적으로 소멸되는 것이 더 좋다고 판단.

⛔생소했던 토큰 인증 방식

  • ✅로그인시 유저정보와 토큰이 넘어 오는데, 이 토큰을 헤더에 넣어 인증이 필요한 api요청을 수행가능

⛔그렇다면 매번 api 요청마다 헤더에 토큰을 넣어줘야하나?

  • ✅토큰을 넣을때, 매번 토큰을 저장하지 않고, 로그인시 스토리지에 저장하여 api통신을 할때마다 axios에 interceptor를 사용하여 헤더에 넣어줌으로써 해결
    예시코드) interceptors.js

⛔인증이 필요한 페이지에 사용자가 임의로 접근이 가능하다.(ex url을 조작하여)

  • ✅인증이 필요한 페이지 접근시 라우터 가드함수를(beforeEnter) 사용하고, 설정하여 인증을 거친후 이동시킴.
    예시코드) router/index.js
    새로운 포스팅을 할때 라우터 설정

🟢사이드바

⛔최초 로그인시 사용자의 정보가 세션스토리지에 저장이되고, 스토리지 안 프로필 이미지를 불러올때, 사이드바 컴포넌트의 computed의 세션스토리지 데이터를 읽는것이 세션 스토리지의 사용자의 정보 저장보다 먼저 인식이 되어 프로퍼티가 없다는 오류와 함께 스토리지 값을 못 읽어옴.

  • ✅ api 응답을 스토리지에 저장하는데, api응답에 없는 프로퍼티를 세션에 저장해놓고, 이를 읽으려 했을때 나는 오류. 스토리지 대신 쿠키를 이용하여 해결
    ex ⛔스토리지)

    ex ✅쿠키)

🟢헤더 검색창

⛔api 구조의 한계

  • api구조가 post들을 불러오려면, 한 채널안의 postid들을 get해오는 방식인데, 우리 프로젝트 특성상 '시' 와 '군/구' 분류가 필요함
  • '시' 채널안에, '군/구' 채널을 만드는 것이 베스트
    우리가 원한 채널구조)
    서울 '시' 채널안에 똑같은 구조를 가진 강남'구' 채널이 자식으로있다.


  • ✅그러나 api 설계 구조상 구현이 힘들다는 답변과 함께, 프론트 단에서 전국의 '시' 채널을 만들어 놓고, 그 안에 description property에 '군/구' 데이터를 넣어둠.
    ex) 대구 '시' 채널 구조

    description property에 '군/구' 데이터를 넣어둠.

⛔검색시 사용자의 입력값 처리

  • ✅초기엔 문자로 검색을 시켰으나, 문자열 예외처리가 시간적인 리소스를 많이 잡아 먹을 것 같아 차선책으로 회유.
  • ✅검색시 유저에게 시 군/구 를 select box로 선택한후, 나머지 주소만 입력
    팀원의 동의를 구하는 모습)

    기존 헤더 검색창

    최종헤더 검색창

🟡글쓰기 페이지

⛔api 문서내 title 프로퍼티만 있어 content를 작성할 프로퍼티가 없다.

⛔api 문서내 location프로퍼티만 있어 사용자가 선택한 위치 처리가 필요하다.

  • ✅title 프로퍼티 안에 '/'를 기준으로 title/content로 데이터를 보낸다.
  • ✅location 프로퍼티 안에 '/'를 기준으로 시/구/상세주소로 데이터를 보낸다.
    ex)

    사용자가 보는 페이지

    실제 데이터 저장

⛔이미지 업로드시 미리보기 & 삭제기능

✅이미지 업로드시 기존 input을 사용하면 이미지 경로만뜨고, 안 이쁘게 나옴. 이를 display:none으로 설정후 vue의 ref와 data를 이용해 미리보기와 삭제 구현.


🟡글 검색-> 포스트 리스트 페이지

⛔포스팅 데이터 가공

  • 사용자가 선택한 '시' 의 채널을 찾은후, 찾은 '시'의 채널안의 포스트의 location안의 '구'를 검사하면서 사용자가 선택한 '구'가 있을경우, 해당 포스트 객체를 검색결과 배열에 push.
    ex) 서울 '시'의 채널 데이터

    ex) 서울 '시'의 채널 안 포스팅 데이터

    location 프로퍼티 안 사용자가 선택한 '구'와 매칭시켜 포스팅 필터링
  • ✅최종적으로 push된 검색결과 배열을 가지고 포스트 리스트를 보여줌.
    코드)

    검색시 필터링을 거처 최종적으로 push된 데이터
{
"_id": "6178f3bf4578ad5c77ea656e",
        "title": "저랑 북한산 등반하실분 초보환영!/초보 환영이에요!!!",
        "location": "서울/강북구/수유동",
        "image": "https://res.cloudinary.com/dyt02nbtq/image/upload/v1635316671/post/db3d07fe-efbd-4e90-a054-10bf4e2c7326.jpg",
        "imagePublicId": "post/db3d07fe-efbd-4e90-a054-10bf4e2c7326",
        "channel": {
            "_id": "617674ad90a200096ef07ceb",
            "name": "서울b",
            "description": "강남구/강동구/강북구/강서구/관악구/광진구/구로구/금천구/노원구/도봉구/동대문구/동작구/마포구/서대문구/서초구/성동구/성북구/송파구/양천구/영등포구/용산구/은평구/종로구/중구/중랑구",
            "createdAt": "2021-10-25T09:11:09.933Z",
            "updatedAt": "2021-11-02T17:12:24.381Z",
            "__v": 0
        },
        "author": {
            "role": "Regular",
            "emailVerified": false,
            "banned": false,
            "isOnline": false,
            "posts": [],
            "likes": [
                "6180d4e84c945d1068226576",
                "6180ef8e00518553478bbc38",
                "61814547e79ef90b013792a8"
            ],
            "comments": [
                "6181570c7471d2113937293d"
            ],
            "followers": [],
            "following": [],
            "notifications": [],
            "messages": [],
            "_id": "6178f3374578ad5c77ea655d",
            "fullName": "dddd",
            "email": "aaa@naver.com",
            "createdAt": "2021-10-27T06:35:35.996Z",
            "updatedAt": "2021-11-02T17:12:24.395Z",
            "__v": 0,
            "coverImage": "https://res.cloudinary.com/dyt02nbtq/image/upload/v1635560944/user/29eff0db-dab0-46a2-b735-420602c6776e.jpg",
            "coverImagePublicId": "user/29eff0db-dab0-46a2-b735-420602c6776e",
            "username": "1339103167292.9817[{\"postid\":\"6179837917a018760c7ba023\",\"state\":\"approve\"},{\"postid\":\"6178f3bf4578ad5c77ea656e\",\"state\":\"approve\"}]"
        },
        "createdAt": "2021-10-27T06:37:51.967Z",
        "updatedAt": "2021-11-02T15:19:40.712Z",
        "__v": 0
    },

사용자가 보는 데이터

⛔새로고침시 사용자가 검색한 결과 초기화

이를 해결하기 위해 router를 이용하여 검색시 url뒤에 '/channelId'을 이어 붙혀 해결시도
그러나 군/구의 데이터는 channel안 post데이터안의 descrition프로퍼티에 존재
router를 이용할시. '시'의 데이터만 유지되게 함.

  • ✅검색결과 배열을 세션스토리지에 저장하여 불러오면서 해결.
    세션스토리지안의 필터링된 데이터들

⛔리스트 클릭 후 사용자가 좋아요, 댓글등 이벤트 발생뒤 뒤로가기를 통해 넘어오면 댓글수, 좋아요 갯수가 갱신되지 않음(새로고침시에는 갱신)

  • ✅사용자가 이벤트 발생시 낙관적으로 데이터를 업데이트 시키면서 해결

🔴Netlify 배포시 functions사용하여 API 숨기기

⛔.env와 VUE_APP 키워드를 사용해 netlify에선 환경변수로 설정해주어 숨기려 했으나 안숨겨짐

  • ⛔결국 functions를 사용하는것이 맞는듯

🙇‍프로젝트를 마치며...

느낀점 & 아쉬운점

서로 공유하는 것이 당연하다는 분위기 만들기.

나는 팀원에게 질문 하는 것이 어려웠고, 물어보는 것이 창피한 일인줄 알았다. 그러나 이렇게 해선 내가 바라던 커뮤니케이션 능력을 향상시킬 수 없다 생각하여 팀원에게 용기내어 물어보았다. 처음이 어렵지, 막상 그 이후에는 바로바로 물어 보고, 의견을 자유롭게 표출 할 수 있었다.
여기서 얻을 수 있었던 마인드는 팀원한테 질문하는 것을 두려워 하지말자. 다. 팀원 코드가 잘 이해가 안된다면 혼자 끙끙 싸매다 시간을 날리지 말고 바로 물어보고, 개선점이 있다면 언제든 얘기하고, 모르는게 있다면 바로 호출하는, 지식을 공유하는 분위기를 형성하는 것이 질좋은 결과물을 도출과 함께 시간절약이 되고, 팀에 좋은 영향을 기여한다는 것을 느꼈다.
그렇다고 팀원의 에너지를 뺏는,(물었던 것 또 물어보기) 김빠지는 질문은 스스로 필터링하여 지양해야 한다. 쓸데없는 질문과 팀에 좋은 방향을 이끄는 질문의 경계를 확실히 하자.

api문서를 완벽히 이해한 다음 개발에 들어갈 것(api문서 검토)

서로 첫 프로젝트이고, 기한도 짧다는 생각에 api문서를 제대로 검토하지 않고, 막상 개발이 어느정도 진행이 되고나서야 우리가 설계한부분과 api설계가 조금 달라 어디서부터 고처야 하는지 난감했던 상황이 있었다. 우리도 몇몇의 수정을하고, 백엔드 api에도 수정을 요청하여 해결 하였으나,
이렇게 매번 수정하고 요청할수는 없으니 개발에 들어가기전에, 충분한 테스팅과 검토를 거처 개발에 들어가고, 만약 여기서 수정사항이 발생한다면, 요구사항을 명확하게 적어 백엔드 단에 전달 해줘야 한다.
개발 시작전에, 앞서 말한 충분한 테스팅과 검토과정을 거치고,(포스트맨 등 이용) 개발설계를 하여 개발에 들어가야 한다고 느꼈다.

mac와 window os차이가 있을시 환경변수 및 경로 고려를 해야한다. 보통 windows에서 잘 동작하는 것은 mac에서도 잘동작한다. window를 기준으로 하자

프로젝트 초기셋팅때 맥과 윈도우의 사소한 차이로(경로인식 이슈등) 으로 시간을 너무 뺐겼던 기억이있다. 보통 windows에서 잘 동작하는 것은 mac에서도 잘동작한다. window를 기준으로 하자

팀원과의 효율적인 역할분배가 어렵다

인과성이 있는 페이지라면
(ex 글을 상세보기를 구현하려면 글 목록이 있어야함.
인증이 필요한 페이지를 구현하려면 인증로직이 완성되어야함 등)
전 단계의 페이지가 완성 되기 전 이라면, 맡았던 페이지의 기능을 완성시키기에 조금 딜레이가 생긴다. UI와 페이지내의 기능을 먼저 구현한다고 한들, 여러가지 요인(앞 단계 페이지의 구현속도, 연결했을때 예기치못한 오류 등)에 의해 효율적으로 시간관리와 역할배분이 안될 수 있다. 따라서
기획단계에서 어느정도 시현을 완성하고, 팀원 각자의 능력에 따라 구현난이도와 필요한 시간을 정해놓고, 최대한의 효율을 논의후 개발에 들어가야 한다.

팀원들 눈치를 보지말자..ㅎㅎ🙄

나는 오늘의 적정량을 끝냈으나 새벽 내내 오래 남아서 불태우고 있는 팀원을 보면 괜스리 눈치가 보인다. (반대의 경우: 나는 새벽같이 하는데 먼저 자버리는 팀원이있네?! )
이렇듯 각자의 사정과 페이스가 있기에 팀원들의 자기 페이스대로 자유로운 분위기속에서 프로젝트를 진행할 수 있도록 분위기를 조성하는 것이 좋은 결과물을 도출하게 하는 조건 중 하나라 생각한다.
나부터 눈치보지 말고 눈치주지 말아야한다.(우리 팀원의 책임감을 믿자)

pr시 설명을 어디까지 적어야 하는가?

우리는 데드라인을 맞추기위해, 쓸데없는 리소스를 제거하고자 pr을 올릴때 설명을 최소화 하고, 대신 스크럼때 자기 pr을 설명하고, 팀원의 피드백을 받고나서 반영까지 하고 난 후 merge를 진행하였다. 회사에가 현업에 들어간다면, 매번 이렇게 소통 할 수 없어 pr을 자세히 적어야 하는데, 이를 미리 연습못해 아쉽다.

추후 🔧리팩토링계획

  • 채팅기능 구현(api 설계상 미루어졌음)
  • 내가 쓴 글 구현(api 설계상 미루어졌음)
  • 카카오 로그인과 연계하여 사용자 인증
  • netlify functions를 이용해 api숨기기
  • 검색시 '시' '군/구' 데이터 유지
  • 받은 피드백 반영
profile
꾸준히 성장하기

0개의 댓글