🍓 딸기마켓

🔗 배포 URL

개요

• 🦁 멋쟁이사자처럼 프론트엔드스쿨 1기 팀 프로젝트로 진행한 딸기마켓입니다.
• 🍓 딸기마켓 서비스는 자신의 스토어에서 판매하고 있는 상품(딸기)을 등록하여 홍보할 수 있는 SNS입니다.
• 🙌 상품을 등록하지 않아도 일상을 공유하며 즐거운 SNS 활동을 할 수 있습니다. 글과 사진과 함께 게시물을 작성하여 자신의 일상을 공유할 수 있습니다. 다른 사용자를 팔로우하면 유저가 올린 게시물을 홈 피드에서 소식을 확인할 수도 있습니다.
• 📝 피드를 구경하다가 마음에 드는 게시물을 발견했다면 댓글을 남길 수 있습니다.

팀원 구성

• 🙋‍♀️ 박누리 🔗github/nurimeansworld
• 🙋🏼‍♀️ 최영은 🔗github/zeroyouth
• 🙋🏻‍♀️ 이지아 🔗github/zeroto99
• 🙋🏽‍♀️ 한희정 🔗github/greenknight03

목차

1. 프로젝트 목표
2. 개발 환경 및 배포 URL
3. 프로젝트 구조
4. 역할 분담
5. 개발 기간 및 이슈 관리
6. UI
7. 페이지 기능
8. 개발하며 겪은 이슈

---

1. 프로젝트 목표

• 개인 판매자가 보다 손쉽게 자신의 상품(딸기)을 판매하는 플랫폼을 제공합니다.
• 현재 판매를 진행하지 않는 잠재 판매자와 고객에게 쉽게 접근 가능한 SNS 플랫폼을 제공합니다.
• 손수 제작한 상품을 등록하여 수익 창출이 가능한 SNS 장터입니다.

(Top)

2. 개발 환경 및 배포 URL

개발 환경

• Front : HTML, CSS, Vanilla JS
• Back : 제공된 API 사용
• 버전 관리 및 이슈 : 🔗GitHub, 🔗GitHub Issues, 🔗GitHub Project
• 서비스 배포 환경 : 🔗 Vercel

배포 URL

URL : 🔗 https://strawberry-market.vercel.app/

(Top)

3. 프로젝트 구조

• assets/ : 이미지, 파비콘, 아이콘 등
• html/ : 개발용 html 디렉토리
• pages/ : 서비스용 html 디렉토리
• js/ : pages의 html과 매칭되는 JS 디렉토리. script.js는 pages 공통으로 사용되는 함수가 등록된 파일

│  README.md
│  index.html
├── assets
├── css
│    ├── default.css
│    ├── font.css
│    ├── reset.css
│    ├── style.css
│    ├── style_HJ.css
│    ├── style_JA.css
│    ├── style_NR.css
│    └── style_YE.css
├── font
├── html
├── js
│    ├── accountedit.js
│    ├── chat.js
│    ├── chatroom.js
│    ├── edit.js
│    ├── followers.js
│    ├── followfeed.js
│    ├── followings.js
│    ├── index.js
│    ├── intro.js
│    ├── join.js
│    ├── login.js
│    ├── mypostedit.js
│    ├── myprofile.js
│    ├── post.js
│    ├── postdetail.js
│    ├── product.js
│    ├── profile.js
│    ├── script.js
│    ├── search.js
│    └── useredit.js
└── pages
     ├── accountedit.html
     ├── chat.html
     ├── chatroom.html
     ├── edit.html
     ├── followers.html
     ├── followfeed.html
     ├── followings.html
     ├── home.html
     ├── intro.html
     ├── join.html
     ├── login.html
     ├── mypostedit.html
     ├── myprofile.html
     ├── post.html
     ├── postdetail.html
     ├── product.html
     ├── profile.html
     └── search.html

(Top)

4. 역할 분담

• 하단 이미지와 같이 개인, 공동 작업 페이지로 나누어 진행하였습니다.
• 프로젝트를 진행하며 API 비교적 중요하다 생각되는 로그인, 회원가입 페이지를 공통으로 진행하였습니다.

🛠 공통 담당

• splash 페이지, 로그인 페이지, 회원가입 페이지

🙋‍♀️ 박누리

• 🔗github/nurimeansworld
• 프로필 페이지, 팔로잉 페이지, 상품 등록 페이지, 상품 수정 페이지

🙋🏼‍♀️ 최영은

• 🔗github/zeroyouth
• 홈 피드 페이지, 채팅 페이지

🙋🏻‍♀️ 이지아

• 🔗github/zeroto99
• 게시글 작성 페이지, 게시글 상세 페이지, 검색 페이지

🙋🏽‍♀️ 한희정

• 🔗github/greenknight03
• 모달 페이지, 하단 탭 메뉴 페이지

(Top)

5. 개발 기간 및 작업 관리

• 전체 개발 기간 : 2022-01-03 ~ 2022-02-13

작업 관리

• 배포용 HTML과 개발용 HTML을 분리하여 작업하였습니다. (🔗 개발용 퍼블리싱 리스트)
• 🔗GitHub Projects와 🔗Issues를 사용하여 진행도와 상황을 꾸준히 공유하였습니다.

주간회의

주간회의를 진행하여 작업 방향이나 코드 고민에 대해 나누었고 GitHub Wiki를 사용하여 기록하였습니다.

• 🔗220202 회의록
• 🔗220128 회의록 (딸기마켓 Reboot 🔥)
• 🔗220114 회의록
• 🔗220112 회의록
• 🔗220107 회의록
• 🔗220103 회의록
• 🔗211228 회의록

(Top)

6. UI

(Top)

7. 페이지 기능

• 상세 기능 설명은 각 페이지별 링크 연결해두었습니다.

1) 홈

🔗splash	🔗로그인 페이지	🔗회원가입 페이지
🔗홈 페이지	🔗검색 페이지	🔗채팅 페이지

2) 게시글

🔗게시글 작성 페이지	🔗게시물 상세 페이지
🔗게시글 수정 or 신고 페이지	🔗댓글 삭제 or 신고 페이지

3) 프로필

🔗마이 프로필 페이지	🔗유저 프로필 페이지	🔗팔로워 페이지
🔗팔로잉 페이지	🔗로그아웃 페이지	🔗프로필 수정 페이지

4) 판매 상품

🔗상품 등록 페이지	🔗상품 수정 페이지
🔗상품 삭제 페이지	🔗상품 사이트로 이동 페이지

(Top)

8. 개발하며 겪은 이슈

1) 코딩 컨벤션, 커밋 컨벤션 정하기

내용

• 협업에 앞서 가독성과 개발 방식 통합을 위해 컨벤션 통일의 필요성에 대해 모두 동의하였습니다.
• 첫 협업에 앞서 다양한 컨벤션 사례와 여러 자료를 서로 찾아보며 공유하였습니다.
• 기존 사례를 무조건 따라가기 보다는 우리에게 더 적합하고 효율적인 규칙에 대해서 고민하는 시간을 가졌습니다.

결론

• 우리만의 코딩 컨벤션, 커밋 컨벤션을 만들었습니다.

  코딩 컨벤션

  코딩 컨벤션

  • prettier 사용 X
  • 들여쓰기 2개
  • reset.css는 http://meyerweb.com/eric/tools/css/reset/ 사용
  • z-index는 10단위로
  • class명은 형태 + 의미 + 상태
  • toast-ko_HTMLCSS, toast-ko_CODING-CONVENTION을 주로 따름
  커밋 컨벤션

  커밋 컨벤션

  Add: 새로운 기능 추가
  Fix: 버그 수정(단순 수정 X)
  Docs: 문서 수정
  Edit : 코드 포맷팅, 누락된 세미콜론 추가 등의 코드 변경은 없고 단순 style 수정
  Refactor: 리팩토링
  Test: 테스트 관련 코드 추가 및 삭제 등
  

2) createElement vs innerHTML

내용

• API로 받아오는 데이터에따라 동적으로 HTML을 추가해야하는 상황에서 어디까지 createElement를 사용하고 어디까지 innerHTML을 사용 할 것인가에 대한 고민이 있었습니다.
• createElement를 사용하는 것이 브라우저 효율쪽이나 여러모로 innerHTML보다 권장되는 방식이지만, 게시글 하나에 들어가는 태그들의 수가 늘어나며 이 모든 것을 createElement로 작성하는 것에 대한 고민이 생겼습니다.
• 또 innerHTML로 생성한 노드는 querySeletor로 선택하지 못하는 문제도 확인하였습니다.

결론

• 예시로 게시글의 경우 하트 버튼에 이벤트 리스너가 추가되어야하는 상황이라 이벤트를 추가해야하는 노드의 경우는 createElement를 사용하여 생성하였습니다.
• 고정된 HTML구조의 경우는 innerHTML로, 데이터에 따라 값이 바뀌는 경우는 createElement로 생성하는 쪽으로 결정하였습니다.

3) button vs a

내용

• 생긴 모양은 button 태그같지만 페이지 이동인지 동작의 수행인지에 따라 a 태그로 사용해야하는 것에 대한 논의를 하였습니다.

결론

• 각 태그의 의미를 고려하여 페이지 이동의 경우에는 a 태그로, 클래스나 데이터가 변경되는 경우에는 button 태그로 사용하기로 결정하였습니다.

4) URLSearchParams

• 게시물마다 지정된 post id를 url에 넘겨줘야 되는 상황이 있었습니다. 해당 데이터를 로컬스토리지에 저장해서 쓰는 거보다 쿼리 스트링으로 쓰는 것이 메모리 효율이나 직관성이 높다는 의견이 나왔습니다. 그래서 URLSearchParams.get 메서드를 사용하기로 했습니다.

(Top)