6/27 3일차

ssongyi·2022년 6월 27일

Beautify Client Side Code Formatter GitHub Commit Rules GitHub branch pattern Prettier bootstrap commit message commit message type css-modules oAuth server side social-login styled components tailwind

MOUM PROJECT

목록 보기

3/33

오늘은 백엔드 분들의 API 명세서를 기다려야하기 때문에 프론트엔드끼리 기능 구현 전 마무리를 짓기로 했다!

오늘 할 일

내가 맡은 파트의 자료조사
- Github commit message rule 조사
- Github branch pattern 조사
- 소셜 로그인(OAuth) --> 서버사이드, 클라이언트 사이드 조사
- 로그인 회원가입 React hook form 조사
프론트엔드끼리 어떤 폼을 사용할지 통일
- beautify, prettier 차이 조사 후 결정
- 'styled component / tailwind + css 모듈' 조사 후 결정
- 카멜케이스 (js 주로 사용)
- 탭 사이즈 (2 size)
CI, CD 연결 : CI, CD 연결방법

자료조사

1. Tailwind + CSS 모듈

Tailwind CSS ?

--> A utility-first CSS framework packed with classes
--> Html을 떠나지 않고도 신속하게 웹 스타일링을 구축할 수 있도록 도와주는
유틸리티 지향 Css Framework

html에 Tailwindcss가 지정해둔 css들을 class로 불러와서 사용하는 형태

축약어로 되어있고 색, 패딩, 마진, 크기 등등 이미 설정이 되어있는 값을 쓰거나 수정하여 쓸 수 있다.

tailwindcss는 Tailwind Css의 코어 패키지이다.

postcss는 Tailwind Css를 우리가 알고 있는 순수 Css로 변환해주는 전처리기 패키지이다.

autoprefixer는 브라우저별로 다르게 지원되는 벤더 프리픽스를 자동으로 넣어주는 패키지이다.

postcss-loader는 Webpack이 Postcss를 읽어들일 수 있도록 해주는 로더이다.

장점
- 간결하고 Html를 떠나지 않기 때문에 개발속도가 빨라진다.
- 반응형 스타일링에 강력하다.
- 클래스 이름을 고민할 필요가 없다.
단점
- Html 부분이 지저분해 보일 수 있다.
- 단순한 편이지만 초기 적응기간이 필요하다.

사용 방법

1. 패키지 설치

$ npm install -D tailwindcss@latest
$ npm install -D postcss@latest 
$ npm install -D autoprefixer@latest
$ npm install -D postcss-loader

2. postcss.config.js

Tailwind Css를 사용하려면 우리가 아는 Css로 변환해주는 전처리기가 필요한데 (그냥 쓰면 못알아듣는다.) Postcss가 그 역할을 해준다. postcss를 설치하였으니 설정파일만 작성해주면 된다.

postcss.config.js

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  }
}

3. tailwind.config.js

다음으로 Tailwind Css의 설정파일도 만들어줘야 하는데, npx로 간단히 Tailwind Css 설정파일을 생성할 수 있다.(직접 작성해도 상관없다.)

$ npx tailwindcss init

tailwind.config.js

module.exports = {
  purge: [],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

4. webpack.config.js

webpack.config.js의 module의 rules배열에 postcss-loader를 추가하면 끝.

  module: {
    rules: [
      {
        test: /.jsx?$/,
        include: [path.resolve(__dirname, "src")],
        exclude: [path.resolve(__dirname, "node_modules")],
        loader: "babel-loader",
      },
      {
        test: /.css?$/,
        exclude: [],
        //로더는 오른쪽부터 읽어들이므로 postcss-loader를 맨 오른쪽에 넣어준다.
        use: ["style-loader", "css-loader", "postcss-loader"],
      },
    ],
  },

5. Tailwind Css 적용

설정이 끝났다면 Css파일을 하나 생성하고, Tailwind Css의 파일들을 가져오자.

styles/global.css

@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

루트 디렉토리에 styles라는 폴더를 만들고 global.css라는 파일을 @import로 가져온 후
index.js에서 global.css를 가져왔다.

src/index.js

import React from "react";
import ReactDom from "react-dom";
import App from "./components/App";
// 추가됨
import "../styles/global.css";

const root = document.querySelector("#root");

ReactDom.render(<App/>,root);

마지막으로 index.js가 렌더링하는 App.js는 다음과 같이 Tailwind Css를 사용하였다.

_src/components/App.js_
import React from "react";

const App = () => {
  return <div className="m-5 bg-yellow-500 text-blue-500 font-bold">
  배워서 나주는 React에 Tailwind Css 적용하기
  </div>
};

export default App;

6. 실행

$ npm start

Tailwind CSS vs Bootstrap

Tailwind

: 빠른 UI 개발로 처음부터 사이트를 구축할 수 있도록 미리 디자인된 위젯을 제공
: 미리 디자인된 위젯은 한 요소가 다른 관련 요소에 영향을 미치는 것에 대해 걱정하지 않고 디자인을 구현하는 데 도움이 된다.
: PurgeCSS를 사용하여 사용하지 않는 클래스를 제거하여 파일 크기를 상당히 줄일 수 있다.

Bootstrap

: 명확한 UI 키트를 보유한, 미리 스타일이 지정된 반응형 모바일 우선 구성 요소 집합이 함께 제공

< Bootstrap의 주요 문제 >

개발자가 특정 추상 패턴에만 의존해야 한다는 것
처음부터 프레임워크를 사용하려는 목적을 완전히 무효화하는 사용자 정의 CSS로 프레임워크를 재정의해야한다.
Bootstrap JS, Popper.js, jQuery를 포함하여 308.25kb 파일 크기가 필요하다.

TailwindCss + StyledComponent

tailwindcss를 태그에 직접 작성을 하다 보면 가독성이 엉망이 되는 것을 느낄 수가 있었고 이를 해결하기 위해서 styled-component를 종종 사용한다.

1. 먼저 tailwind-styled-component를 설치

npm i -D tailwind-styled-components

[https://www.npmjs.com/package/tailwind-styled-components](tailwind-styled-component 링크)

2. 설치한 모듈을 작성하려는 파일에 적용

import tw from "tailwind-styled-components";

3. ex)

처음 가독성이 좋지 않았던 부분

일단 가장 보기 힘든 부분이 li태그이므로 li태그를 styled-component로 정리

이제 전에 있던 li태그 대신에 NavbarLi를 넣어주면 된다.

2. beautify, prettier 차이 찾기

Code Formatter ?

개발자가 작성한 코드를 정해진 코딩 스타일을 따르도록 변환해주는 도구

VSCode Extension 중 Javascript Code Formatter로는 대표적으로 Prettier와 Beautify가 존재한다.

Prettier

스타일 형식이 대부분 강제.
prettier: (Star: 40.3k, Used by: 3.1m, Contributors: 546)
prettier-vscode: (Star: 3.9k, Contributors: 74)
.prettierrc을 사용 (옵션 21개)
Code Formatter에 대해서 VSCode를 사용한다면 workspace setting의 Format On Save를 체크하면 ctrl + s를 누를 때마다 Code Formatting을 해준다.

Beautify

Prettier보다 자유로운 스타일 형식 지정 가능.
js-beautify: (Star: 7.4k, Used by: 350k, Contributors: 182)
VSCodeBeautify: (Star: 535, Contributors: 12)
VSCode는 내부적으로 js-beautify를 사용한다. (링크)
.jsbeautifyrc을 사용 (옵션 25개)
Code>Preferences>Keyboard Shortcuts를 누르면 단축키를 설정할 수 있다.

기능적인 지원에서는 Prettier가 Beautify보다 적은 명령어를 보유하고 있음에도 불구하고 훨씬 다양했다.(e.g. arrow function, JSX 고려 등)

옵션 이름에서도 Beautify보다 Prettier가 명확하고 다양한 기능을 제공한다는 것을 한눈에 알 수 있다.

또한, Prettier는 여러 형식(e.g. babel, markdown, graphql, yml, typescript 등 21개의 다양한 형식을 지원한다.)을 지원하고 있다.

기능이 더 다양함에도 Prettier의 Option 개수가 적은 이유는 스타일에 대한 모든 진행 중인 논쟁을 중단하는것에 목적이 있기 때문이다. 따라서, 최소한의 논쟁의 여지가 있는 Option들을 제외하고는 스타일을 강제한다.

3. 깃허브 커밋 메시지 규칙

제목과 본문을 한 줄 띄워 분리하기
제목은 영문 기준 50자 이내로
제목 첫글자를 대문자로
제목 끝에 . 금지
제목은 명령조로
본문은 영문 기준 72자마다 줄 바꾸기
본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기
(8. 커밋 메시지로 Github 이슈(issue)를 자동 종료시키기)

Commit Message 구조

type(타입) : title(제목)

body(본문, 생략 가능)

Resolves : #issue, ...(해결한 이슈 , 생략 가능)

See also : #issue, ...(참고 이슈, 생략 가능)

Commit Message 의 타입(type)

- FEAT : 새로운 기능의 추가
- FIX: 버그 수정
- DOCS: 문서 수정
- STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
- REFACTOR: 코드 리펙토링
- TEST: 테스트 코트, 리펙토링 테스트 코드 추가
- CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)

4. 깃허브 브랜치 패턴

MASTER / DEVELOP 가 대부분 기준점이자 시작점

Master (Main Branch)
Develop (Main Branch)
Feature/<Issue_number> or <Feature_name> /
Release/<version_number>
Hotfix/<Issue_number> or Issue/<Issue_number>

1. Master Branch

Release(배포)출시 할 수 있는 브랜치
최종 배포(Release) 이력을 관리하기 위한 최상위 브랜치입니다.
배포 가능한 상태만을 관리합니다.

2. Develop Branch

다음 출시 버전을 개발하는 브랜치
Master에서 분기되어 기능 개발을 위한 브랜치들을 병합하기 위해 사용 합니다.
이 브랜치를 기반으로 개발을 진행. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)합니다.

3. Feature branch

기능을 개발하는 브랜치 (Local)
feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기합니다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 주로 자신의 로컬 저장소에서 관리합니다.

개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다.

‘develop’ 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.
새로운 기능에 대한 작업 수행한다.
작업이 끝나면 Local에서 개발한 Feature 브랜치를 develop에 병합한다.
더 이상 필요하지 않은 feature 브랜치는 삭제한다.
새로운 기능에 대한 ‘feature’ 브랜치를 중앙 원격(Remote) 저장소에 올린다.(push)

4. Release Branch

이번 출시 버전을 준비하는 브랜치
Feature branch에서 Develop 브랜치로 어느정도 배포가 진행되고 배포할 수있는 시점(모든 기능이 정상인 상태 or 목표개발기간종료) 이 되었을때 Release Branch를 생성한다.
그 이후 테스트를 통해 최종적으로 버그 수정이라든가, 문서 추가등 실질적으로 Release 출시 하기 직전에 하는 단계들을 위한 브랜치다. 만약 버그수정이 있다면 수정하고 Develop 에다가도 병합해줍니다.
기능에 대한 병합작업은 하지 않는 단계이며 마지막 검토 정도로 생각하면 된다. 기능에 대한 개발은 계속해서 Develop 이나 Feature Branch에서 이어나간다.

그리고 모든 버그나 문서 수정이 완료 되면 Master Branch로 병합 및 버젼 Tag를 부여하여 출시 한다.
또 배포를 준비하는동안에 Release 브랜치가 변경되었을 수 있기때문에 배포 완료후에 Develop 에다가도 병합한다.

EX) release/1.2

소프트웨어 번호 관리는 보통 SemVer (Semantic Versioning의 줄임말) 버전의 형식은 [Major].[Minor].[Patch]

5. Hotfix Branch

출시 버전에서 발생한 버그를 수정 하는 브랜치
배포를 했지만 갑작스럽게 수정해야하는 경우에 master에서 바로 수정하지 않고 Hotfix 브랜치를 분기하고 고친후 병합한다. <master에서 수정하는일은 거의 없음, 분기후 수정>문제가 되는 부분만을 빠르게 수정한다.
존재의 이유는 갑작스럽게 수정해야 하는 부분이며 Patch 버젼(1.2.1)을 새롭게 변경해준다.
그리고 배포가 끝난후 다시 develop에다가도 병합해 준다.

전체 흐름

5. 소셜로그인 서버사이드 vs 클라이언트 사이드

소셜로그인을 구현하는 방법은 크게 두 가지다.
하나는 클라이언트 사이드에서 플랫폼과 정보를 주고 받는 것이고,
다른 하나는 서버사이드에서 정보를 주고 받는 것이다.

클라이언트 사이드

클라이언트에서 정보를 플랫폼에 발송
플랫폼에서 클라이언트로 토큰 발송
클라이언트에서 서버로 토큰 전달
서버에서 토큰을 가지고, 플랫폼에 유저 정보를 요청
유저 정보와 서버에서 생성한 자체 토큰을 클라이언트로 전달

장점 : 단순하고 직관적으로 정보를 주고받기 때문에, 손쉽게 로그인을 구현할 수 있다.
단점
- 유저가 클라이언트를 사용하고 있을 경우에만 구글 API에 접근할 수 있다. 즉, 사용자가 웹 앱을 떠나면, 작업이 중단될 수 있다. 서버 사이드로 구현한 경우에는 사용자 대신 백그라운드 작업을 수행할 수 있다.
- 구글 iframe이 특수 쿠키를 사용하여 구글 계정을 표시하므로, 브라우저에서 타사 쿠키를 비활성화한 경우 로그인이 동작하지 않을 수 있다.

서버 사이드

클라이언트에서 정보를 플랫폼에 발송
플랫폼에서 서버로 토큰 발송
서버에서 토큰을 가지고 플랫폼에 정보 요청
유저 정보와 서버에서 생성한 자체 토큰을 클라이언트로 전달하는 과정으로 진행된다.

로그인 시나리오

클라이언트에서 서버에 로그인 요청을 한다.
서버는 소셜로그인을 한다.
2.1 서버는 인증서버에 Authorization Code를 요청한다.
2.2 인증서버의 로그인 페이지로 이동
2.3 인증서버는 사용자에게 ID,PW를 입력받고, 서비스 이용하기 위한 정보 제공 동의를 받음
2.4 인증서버는 Authorization Code를 Redirect URI에 전달한다.
2.5 서버는 전달 받은 Authorization Code를 기반으로 Access Token, Refresh Token(소셜 서버의 토큰)을 요청하고 받는다.
서버는 사용자정보를 저장하고 로그인 처리를 한다.

ssongyi

이전 포스트

6/25 2일차

다음 포스트