Portfolio

정했으면 하는 것 : 역할/ 컨벤션/ 프로젝트 새팅 / 팀문화 등

역할

컨벤션

📣

아래 네가지에 대해서 원하는 컨벤션 적어주세요! 참고한 링크있으면 같이 두어도 좋아요~.~

민수님

건호님

동건님

참고자료 : commit = 예진님꺼, PR = 참고링크

Commit 컨벤션

feat	새로운 기능을 추가할 경우
fix	버그를 고친 경우
rename	파일 혹은 폴더명을 수정하거나 옮기는 경우
design	단순 디자인 변경
refactor	프로덕션 코드 리팩토링
chore	자잘한 수정 사항 전부

Pull Request 컨벤션


### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 반영 브랜치
ex) feat/login -> dev

### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.

### 테스트 결과
ex) 베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있습니다.

ㅤ

예진님

https://overcome-the-limits.tistory.com/entry/협업-협업을-위한-기본적인-git-커밋컨벤션-설정하기

키워드 시작 대소문자는 협의했으면 좋겠다.

커밋내용에서 설명은 한국어를 지향합니다

깃커밋이모지는 좋아하지 않습니다 ㅎ


Feat: 입력 폼 추가
Fix : input 태그 submit 로직 수정

feat	새로운 기능을 추가할 경우
fix	버그를 고친 경우
rename	파일 혹은 폴더명을 수정하거나 옮기는 경우
remove	파일을 삭제하는 작업만 수행한 경우
design	CSS등 사용자 UI 디자인 변경
comment	필요한 주석 추가/삭제/수정한 경우
docs	문서를 수정한 경우
style	코드 포맷(세미 콜론, prettier) 수정한 경우
refactor	프로덕션 코드 리팩토링(변수명 개선 등)
chore	빌드 태스크 업데이트, 패키지 매니저 설정 (실제 production 코드 변경은 없음) ex. package.json 변경, 그외 자잘한 것
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우

prettier

민수님

"tabWidth": 2

중첩된 컴포넌트를 사용할 경우 탭 크기가 작을 수록 코드의 깊이가 깊어져도 코드를 읽기 쉽다고 생각하기 때문..

건호님


{
    "tabWidth": 2,
    "bracketSpacing": true, // 객체 괄호에 공백 삽입 -> { a: 1, b: 2, c: 3 }
    "endOfLine": "lf", // OS에 따라 고려 필요함//
    "semi": true,
		"trailingComma": "none", // 코드 맨 마지막에 ',' 쉼표 기호 붙지 않게끔
}

동건님


{
    "tabWidth": 4,
}

예진님

https://velog.io/@hoonystory98/Prettier

https://adjh54.tistory.com/20


{
  "singleQuote": true,
  "endOfLine": "lf",
  "singleAttributePerLine": true, 
  "bracketSameLine": true, // xml에서 닫는태그(>)가 혼자 아래있는대신 같은 줄 마지막에 있는게 깔끔한 것 같습니다. (true: 줄넘김안함)
}

eslint

민수님

건호님


{
	"no-unreachable": "warn", // 도달할 수 없는 코드를 금지. return, throw, break 이후의 코드를 뜻함.
}

동건님

유니콘 알아보는 중…

예진님


"no-unused-vars": "warn", // 사용하지 않는 변수 금지
"react/jsx-key": "error", // 반복문으로 생성하는 요소에 key 강제


module.exports = {
  root: true,
  env: { browser: true, es2020: true },
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:react-hooks/recommended',
  ],
  ignorePatterns: ['dist', '.eslintrc.cjs'],
  parser: '@typescript-eslint/parser',
  plugins: ['react-refresh', '@typescript-eslint', 'react'],
  rules: {
    'react-refresh/only-export-components': [
      'warn',
      { allowConstantExport: true },
    ],
    'no-unused-vars': 'off', // 사용하지 않는 변수 금지.ts와 충돌때문에 off 하고 아래 처럼 설정
    '@typescript-eslint/no-unused-vars': 'warn', //'error'
    'react/jsx-key': 'error',
    'no-unreachable': 'warn',
  },
};

naming

- 파스칼 케이스, 카멜 케이스, 스네이크 케이스, 케밥 케이스, 한글 변수
- 클래스, 상수, 변수, 컴포넌트, 커스텀 훅, 유틸리티, 타입

민수님

건호님

대문자 스네이크 케이스 : 상수


const API_END_POINT = ‘url’;

카멜 케이스 : 변수, 함수, 메서드 이름


const userName = 'Kim';

const getUserName = () => {};

파스칼 케이스 : 컴포넌트 이름, 클래스


class User extends ~

function App() { ~ }

유틸리티 폴더 명은 모두 끝에 s를 붙이는게 어떨까요?


if(true) return; // return, break, throw 등에 대해서만 { } 없이
if(true) {
	state = newState
}

동건님

참고링크

container는 주로 여러 개의 요소를 감싸는 div이고,

wrapper는 단일 요소의 레이아웃을 위한 div를 말한다.

HTML/CSS 네이밍 시 container와 wrapper의 차이

참고 : https://stackoverflow.com/questions/4059163/css-language-speak-container-vs-wrapper 모달 컴포넌트를 만들다가 문득 container와 wrapper의 차이가 궁금해졌다. 퍼블리싱할 때 별 생각 없이 혼용해서 사용하던 단어였는데 규칙이나 관례가 있는지 찾아봤는데 stackoverflow의 한 답변이 가장 잘 정리되어 공유한다. 둘다 레이아웃을 위한 div지만 container는 주로 여러 개의 요소를 감싸는 div 이고, wrapper는 단일 요소의 레이아웃을 위한 div 를 말한다.

https://ryusm.tistory.com/134

예진님

컴포넌트


const __ = () => { } //표현식

커스텀훅 : usePascalCase

함수 : camelCase

동사+명사 (Ex)getUserList, onChangeInput
boolean을 반환할경우 is~ (Ex)isLoading

이벤트 핸들러 handle+명+동


const handleModalOpen = () =>{ }

컴포넌트의 props로 넘길땐


<Modal onModalOpen = {handleModalOpen} />

props의 이벤트핸들 속성값 가능하다면 최대한 구체화. (Ex)onClick 보단 onCloseClick

타입,인터페이스 prefix

단일 타입 - 타입선언
객체 등 이외 - 인터페이스

props에 대해선 ~Props


type TodoType  { ...


interface ITodo { ...}
interface AppProps { ...}

코드 스타일

CSS 속성 정렬 순서

참고자료 : https://milooy.github.io/TIL/CSS/css-property-order.html#intro

프로젝트 세팅

📣

원하는 기술, 해보고 싶은 기술에 대해서 왜 써야 하는지 설명 부탁드립니다 :)

기술스택

동건

styled-component

tailwind 보다 사용성 높음
용량이 현저히 낮음
여태까지 배웠던 sass 문법을 그대로 쓸 수 있음

graphQL

rest API와 같이 적재적소에 사용하면 사용성 극대화 할 수 있다고 들음

번들러, 패키지

동건

vite

자잘한 설정 없이 갖다 쓰기 너무 좋음
빌드 시간 빠름
필요한 설정들이 잘 갖춰져 있음

상태관리

동건

custom hook으로 만든 전역 상태 관리툴

custom hook으로 만드는 거라 용량 자체가 없다시피 함
리액트에서 어떤 원리로 전역 상태가 관리되는지 알 수 있음
포트폴리오에 상태 관리툴 직접 만들어봤다고 하면 플러스 점수 있을 것 같음
상태 관리툴 러닝 커브를 어느정도 상쇄할 수 있음

스크럼방식 (팀문화)

회고

컨벤션 제안