styled components / emotion/styled
성능상 유의미한 차이가 나지 않는다. emotion의 퍼포먼스가 전반적으로 더 좋게 나오고있다.
emotion이 번들의 크기가 더 크다. 동일 코드로 번들크기가 더 증가한다.
css-in-js
장점
css파일의 유지보수가 필요없어진다. 단일파일에서 관리가 가능하다. js의 코드를 활용할 수 있다.
해당 DOM에서만 활용할 수 있는것도 장점, js와 css사이에있는 상수와 함수를 공유할 수 있다.
단점
러닝커브가 높다. (기술 또는 지식을 실무와 같은 환경에서 효율적으로 사용하기위해 드는 학습비용)
별도의 라이브러리를 필요로해서 크기가 커질 수 있고, 디자인페이지를 작업한다면 csss 모듈방식에비해 느린 성능을 보여줄 수 있다.
==>>> 스타일드컴포넌트를 계속해서 사용했어서 러닝커브에대한 단점이 커버된다고 생각해서 선택함
ajax / axios / fetch
ajax - 기존에 사용되던 JS 내부라이브러리 통신방법
코드가 매우 지저분했으나 JQuery에서 Ajax를 편리하게 사용하는 방법을 제공하면서 두개를 같이 쓰게됨
JQuery를 통해 코드가 간단하고 직관적이게 변하고, 브라우저간 호환성에 대해서도 보장이됨
axios - node.js 와 브라우저를 위한 HTTP통신 라이브러리
비동기로 통신을 가능하게해주며 return을 promise 객체로 해주기 때문에 response 데이터를 다루기도 쉽다.
그래서 react에서 fetch보다 axios를 선호한다.
fetch
ES6부터 JS의 내장 라이브러리에 추가됨.
promise기반으로 만들어졌기에 axios와 마찬가지로 데이터를 다루기 어렵지 않으며, 내장 라이브러리라는 장점으로 편리
하다.
axios vs fetch
axios
- 장점
- -- response timeout 처리방법이 있다.(fetch에는 존재안함)
- -- promise기반으로 다루기가 쉽다.
- -- 크로스 브라우징에 신경을 많이써 브라우저 호환성이 뛰어나다.
- 단점
- 모듈 설치를 해주어야한다.
fetch
- 장점
- 내장 라이브러리로 별도의 import을 해줄 필요가 없다.
- promise기반으로 다루기가 쉽다.
- 내장 라이브러리이기에 사용하는 프레임워크가 안정적이지 않을 때 사용하기 좋다.
- 단점
- explorer의 경우 fetch를 지원하지 않는 버전이 존재한다. (브라우저 호환성이 떨어짐)
- 기능이 부족하다.
reactjs, vuejs등 웹 프론트 프레임워크를 다룰떄에는 axios를 사용하는 것이 더 좋다고 생각됨
axios는 크로스 브라우징에 신경을 많이 썼으며, 기능또한 우수하기 때문
다만, react-native는 아직 안정화된 프레임워크가 아니기에 지속적인 version update가 진행되고있고, axios에서 이를 반영
하지 못할 경우 생각지 못한 에러가 발생할 수 있기에 fetch사용이 나을수도있다.
=====> reactjs를 사용하여 웹브라우저 서비스를 만들기도하고, axios에 익숙하기때문에 axios를 선택함
CI/CD
CI/CD는 지속적 통합(Continuous Integration) / 지속적 배포(Continuous Deployment) 또는 지속적 제공(Continuous Delivery)의 줄임말로, CI는 한마디로 빌드 및 테스트 자동화 과정, CD는 배포 자동화 과정을 의미한다.
CI - 지속적인 통합으로, 새로운 코드가 작성되었을 때 주기적으로 빌드 및 테스트가 진행되면서 공유되는 repository에 merge되는 것
CD - 지속적인 배포(제공)으로, CI단계를 거친 코드를 실제 운영 서버에 자동 배포 하는 것
>>>>>>한마디로, 개발, 빌드, 테스트, 배포까지 모든 단계를 자동화하여 사용자에게 빠르게 배포하는 것이다.
CI
github과 같은 형상관리 시스템에 계속 커밋하고 통합합니다. 통합한 코드를 빌드하고 테스트하여 버그가 발생하면 버그를 해결합니다.
이 과정에서 빌드와 테스트를 자동으로 진행해주면 아래와 같은 장점이 있습니다
- 여러 개발자가 관련된 코드를 작업하여 발생하는 충돌문제를 해결할 수 있다.
- 커밋 할 때 마다 빌드와 자동 테스트가 이루어져 잘못된 merge를 예방할 수 있다.
- 코드 검증에 들어가는 시간이 줄어들며, 개발 편의성이 좋아진다.
repository의 특정 브랜치에 push가 되었거나, PR을 요청하였을 때를 확인하여 코드 테스트 및 통합을 할 수 있도록 합니다.
CD
공유 repository에 통합된 코드가 CI 단계를 마쳤다면 해당 코드는 배포할 준비가 됐다.
이 코드를 자동으로 배포하여 사용자는 항상 최신 버전의 서비스를 사용할 수 있게 됩니다.
배포를 자동화함으로써 deploy를 때마다 하지 않아도 되며 배포보다 개발에 집중할 수 있게 됩니다.
- 지속적 제공 (Continuous Delivery)
- CI를 마치고 릴리즈가 가능한 상태라면 배포까지 자동으로 해주는 것
- 지속적 배포 (Continuous Deploy)
- CI를 마치고 릴리즈가 가능한 상태라면 사람의 검증을 통해 수동으로 배포하는 것
react-datepicker / swiper
- 와이어프레임에서 원하던 날짜 선택 디자인, 기능과 캠핑장 이미지를 slide형식으로 보여주는데 적합한 라이브러리라 판단하였다.
- 두 라이브러리 모두 타입스크립트와 호환되며, 사용자가 많은 라이브러리이기 때문에 사용 방법을 찾기에 용이하기 때문이다.
typescript
- 리액트와 타입스크립트는 호환성이 좋고, CRA를 할 때 간단하게 타입스크립트를 적용할 수 있는 방법이 있기 때문이다.
- 코드에 목적을 명시하고 목적에 맞지 않는 타입의 변수나 함수에서 에러를 발생시켜 버그를 사전에 방지한다.
- (실제경험)실전 프로젝트 전 타입스크립트를 사용하지 않았을 때, 타입에따른 오류가 자주 발생했었다. 따라서 해당 오류들을 사전에 방지하기 위한 선택이었다.
Meterial UI
- 호스트페이지에 대한 디자인 시안이 따로 없이 빠르게 개발을 해야했으므로 시간을 줄이기위해 mui를 선택함
- 리액트와의 호환성이 높고, 사용자가 많아 라이브러리에대한 신뢰성이 높기 때문에 선택함
'1차 공부 > WIL' 카테고리의 다른 글
| 항해 10주차 실전프로젝트 (5) (1) | 2023.02.05 |
|---|---|
| 항해 10주차 실전프로젝트 (4) (0) | 2023.01.30 |
| 항해 9주차 실전프로젝트(2) (0) | 2023.01.15 |
| 항해 8주차 실전프로젝트(1) (0) | 2023.01.08 |
| 항해 7주차 클론코딩 (0) | 2023.01.01 |