프론트 변수 컨벤션

상수

일반 적으로 모든 변수명은 camel case 를 따른다

const foo = { foo: "var" }; ✅
let str = "str" ✅
let someName = "someName"; ✅
let somename = "somename" ❌
const handleClickSomeButton = () => { return "hello world" }; ✅

재할당 불가능 && read only, freeze, tuple 는 uppperCase

const VAR = { foo: "var" } as const; ✅
const ARR = [1, 2, 3] as const; ✅
const ARR: [number, number] = [1, 2]; ✅
const enum SOME_ARR {
    KEY = "value",
} ✅
const STR = "STR" ✅

변수를 사용하여 문자열 변수를 생성 할 경우

const some = `${name}/${hello}`; ✅
const some = `${name}${hello}`;  ❌
const some = name + hello; ✅

컴포넌트(함수)

일반적으로 선언식으로 함수를 생성한다 선언식과 표현식에 따른 컨텍스트 차이와 this 의 차이를 생략한다

일반적인 react 프레임워크 생태계에서는 typescript를 사용하고 함수형을 사용하기에 무시 가능 (일반적으로 lint에 의해 this 사용시 에러 발생)

공통적으로 첫글자를 대문자로 사용하며 파일 이름 역시 첫글자를 대문자로 사용한다.

// 선언형
function SomeFunc() { return "선언식" } 
// 표현식
const SomeFunc = () => { return "표현식" }

폴더 구조 (next14 appdir ver)

현재 사용하고 있는 방식

src
    ㄴ actions //  "use server " 지시어가 붙어있는 함수들 ( jsx 엘리먼트를 포함하지 않음 )
    ㄴ app    // 각종 페이지 진입점 (route 역할)
    ㄴ lib    // 프로바이더, 유틸, 전역 상수 파일 집합 그룹
    ㄴ components    //  재사용가능한 혹은 단일로 사용가능한 모든 컴포넌트 집합 그룹
    ㄴ database        // prisma, drizzle, kysely 등 본인이 사용하고자 하는 데이터베이스 전용 폴더 (주로 db를 가져오거나 db 테이블 타입이 포함되어 있음)
    ㄴ apis     // next fetch를 사용하는 함수들 집합 그룹 (ex  getUsreInfo.ts )
    ㄴ schema  // zod 전용 폴더, 각장 스키마 파일이 존재 (ex getUserInfoSchema.ts )
    ㄴ store        // 전역 상태관리 라이브러리 전용 폴더 ( jotai, zustand, react-query )

css(스타일)

tailwind.css

git

기본적으로 rebase 를 사용한 브랜치 관리

특별한 이유는 존재하지 않으며, 누구나 보기 쉬운 브랜치 형상을 위함

feat: 기능 개발, 직접적인 로직 수정, 로직 수정과 혼합되어 있는 tailwind 인라인 수정 등
fix: semantic versioning 에 따라 마이너 버전 혹은 버그 픽스 버전 어디쪽에 영향을 끼치는지 판단, jira 등 외부에 의해 버그로 판단된 경우
chore: semantic versioning 에 영향이 가지 않는 파일 수정 - gitignore, next.config.mjs, prettierrc, package.json 등
style: semantic versioning 에 영향이 가지 않는 style 수정
test: semantic versioning 에 영향이 가지 않는 테스트 파일 수정

우선순위 feat > fix > chore > test > style

부득이하게 하나의 커밋건에 위 접두어가 복수이상 포함될 경우가 아니라면 커밋은 나눠서 올린다 커밋 컨벤션 을 따른다

컴포넌트 props 관리

네임스페이스❗

namespaces Some {
  export interface Props {
    name: string
  }
}

function Some(props: Some.Props) {
  return <div>hello</div>
}

esmodule export ❗

export type Props = {
  name: string
}

function Some(props: Props) {
  return <div>hello</div>
}

esmodule export 를 따른다.

컴포넌트 props 타입

1. 일관적으로 props를 타입을 따로 작성한다
2. 구조분해 할당을 베이스로 한다 ( 기본적으로 프로젝트 내에서 옵셔널한 변수 대한 사용을 지양 ) ( 옵셔널한 값은 구조분해 할당이 되지 않음 )

type Props = {
  name: string;
}

function Some(props: Props) {
  const { name } = props;
  return "Some";
}

boolean 타입의 접두어를 강제한다

1. use
2. has
3. is

컴포넌트끼리 레이아웃 구성하기

1. A 컴포넌트와 B 컴포넌트가 존재한다면 두 컴포넌트 사이의 gap은 동적으로 구성한다.
2. 컴포넌트는 순수하게 자신의 영역만 가지도록 설계한다. padding과 margin은 wrapper 를 이용한다

function Some() {
    return "hello";
}

function Name() {
  return "name";
}

function FlexBox(props: Props) {
    const { children, gap. width, heght, direction = "row" } = props;
    return (
        <div className="flex" style={{ gap, width, height, flexDirection: direction }}>
            {children}
        </div>
    )
}

function Main() {
  return (
    <FlexBox gap="2rem">
        <Some />
        <Name />
    </FlexBox>
  )
}

function Main2() {
  return (
    <FlexBox gap="1rem">
        <span>this is title</span>
        <FlexBox gap="2rem">
            <Some />
            <Name />
        </FlexBox>
    </FlexBox>
  )
}

// Main3.scss
.container {
    padding: 3rem;
}

// Main3.tsx
function Main3() {
  return (
    <div className="container">
        <FlexBox gap="2rem">
            <Some />
            <Name />
        </FlexBox>
    </div>
  )
}