운좋게도 OKKY를 통해 연결된 다른 세 분의 현직/예비 개발자분들과 함께, 토이 프로젝트를 진행하기로 했다.
(감사 감사)
나는 프론트로 배정! 리액트 기술을 사용해볼 것이다.
회의록
- 회의1 (20210330)기획 설명.
기간: 3~4주 계획 우선 기획안에 있는 기능 구현 후
나머지 아이디어에 올라온 기능 중 골라서 추가하는 방향으로 갈 예정. - F HS님 리딩, HR님 hook /styled-componets / yarn /
Context APIRedux - B HY님 리딩, SH님 Spring-boot / MariaDB / JPA / AWS >네이버 클라우드 플랫폼 Gradle 기반 자바 프로젝트
- Github 1repo안에 2개의 client폴더와 server폴더로 분리해서 유지
프론트 기술 선택의 이유
- 개발할 때 기술 스택 선택에는 이유가 있어야 한다.
- 개발 과정에서 변화가 있을 수 있지만, 초기 선택의 이유를 기록해본다.
1. Hook 사용
Hooks are a new addition in React 16.8.
They let you use state and other React features without writing a class. - reactjs.org
- React Component는 class형 vs. function형 있음
- state관리, life cycle method는 class형의 전유물이었으나
- hook (2019) 을 사용하면 function형 컴포넌트에서도 가능
- 코드의 간략화
- Logic의 재사용화
- 성능 개선
참고 - reactjs.org/docs/hooks-intro.html
참고 - codingbroker.tistory.com/23
2. styled-components
Utilising tagged template literals (a recent addition to JavaScript) and the power of CSS, styled-components allows you to write actual CSS code to style your components. It also removes the mapping between components and styles – using components as a low-level styling construct could not be easier! - styled-components.com
- styled-components는 대표적인 CSS-In-JS
- CSS 스타일을, 따로 CSS파일에 저장하는 것이 아니라, JS로 작성된 Component에 바로 정의하는 것
- React/Angular/Vue등의 모던 JS 라이브러리리 사용을 바탕으로, 웹페이지를
- HTML/JS/CSS로 분리하는 것이 아니라,
- 기능에 따라 컴포넌트로 분리한 후,
- 각 컴포넌트에 세 구성요소를 모두 포함
: JSX로 - JS에 HTML 포함
: CSS-In-JS로 - JS에 CSS 포함
참고 - styled-components.com/docs
참고 - www.daleseo.com/react-styled-components/
NOTE. 스타일링 시 주의할 점...
- 함수형 컴포넌트가 렌더될 때, 함수 안의 부분이 다시 실행됨
- useCallback (함수 캐싱), useMemo (값 캐싱)은, 배열부분이 바뀌지 않는 이상 같은 값으로 인식
- 컴포넌트의 return 부분 안에서도, 달라진 부분만 리렌더링됨
(a) inline style을 사용한다면?
<div style = {{marginTop: 10}}>
- 이런 식으로 inline css style을 정의하면,
{{}}가 객체로 인식된다.
- 리액트 사용 시 Virtual DOM을 계속 살펴보면서
달라진 게 있을 때마다 페이지를 업데이트 하는데,
- 객체 생성은 변화로 인식되어서 (ex. {} === {} //false)
실제로 바뀐 게 하나도 없는데도,
함수가 call될 때마다 새로운 객체가 생성되고, 리렌더링이 된다.
(b) 반면 styled-component사용으로
import styled from 'styled-components';
const ButtonWrapper = styled.div`
marginTop: 10px;
`;
이미 style이 적용된 div컴포넌트를 만들고
이를 사용하기만 하면 리렌더링 최적화할 수 있음
(c) 혹은 useMemo (React Hooks)를 이용해
import {useMemo} from 'react';
const style = useMemo(() => ({marginTop: 10}), []);
<ButtonWrapper style={style}>
styled-component 없이 값을 캐싱하여
리렌더링돼도 같은 객체를 유지할 수 있음
(d)
- 즉, styled-component나 useMemo는 새로운 객체 생성을 막아 리렌더링 최적화에 도움을 준다.
- 하지만 이 둘은 코드의 길이를 늘리므로, 성능 최적화에 크게 신경 쓰지 않는다면 (아주 작은 앱이라면), inline사용도 고려.
참고 - www.inflearn.com/course/노드버드-리액트-리뉴얼
리렌더링 관련 좋은 글
3. Yarn vs. npm
- yarn과 npm 모두 노드 패키지를 설치 및 관리해주는 툴이다.
- Compatibility/Stability 향상을 위해 페이스북 팀이 yarn을 개발했지만,
- 현재는 Performance / Compatibilty / Stability 모두 큰 차이 없음
- 원하는 패키지마다 그 때 그 때 적합한 package manager tool을 쓰면 될 것 같다.
참고 - yarnpkg.com/getting-started/qa#is-yarn-faster-than-other-package-managers
참고 - ehddnjs8989.medium.com/npm-vs-yarn-3a611c89d291
4. Context API Redux 사용
- 컴포넌트가 많아지면 부모-자식간의 소통이 복잡해짐
- states - props 통신 과정에서 불필요한 소통이 많아질 수 있고,
- 모든 컴포넌트를 관리해야하는 App에 큰 부담이 올 수 있음 (너무 복잡)
- 따라서, 중앙 저장소를 만들고 모든 컴포넌트를 이와 연결,
- 중앙 저장소의 데이터가 변경되면 이와 연결된 컴포넌트들의 변경을 야기하는 구조가 편함
- 이런 중앙 저장소역할을 할 수 있는 것이
: Context API, Redux, Mobx, GraphQL 등등...
- 이 중 인기있는 Context API와 Redux의 큰 장점으로는,
- Context API
- React의 built-in tool이어서 따로 설치할 필요 없음 -> 앱 용량 비교적 작음
- 이를 사용하기 위한 기본 코드 (boilerplate code)가 적음
- Redux
- 크기와 코드량이 많은 대신, 에러 트래킹이 편리함
- redux-think / redux-saga 등으로 비동기 액션 처리가 편리함
- 앱 크기가 커지면 성능면에서 비교적 뛰어남
- data sharing 등 상태 관리 이상의 작업을 수행할 때 훨씬 편리함
- 일단은 이 프로젝트는 가볍게 만들어보기 위해, 또 React의 built-in tool을 잘 이해하기 위해, Context API를 사용하는 것으로 결정.
- 현업에서 리덕스가 많이 쓰이고,
비동기 액션 처리를 위해 Context API는 manually 코드 구현 해줘야 하며
에러 트래킹을 잘 하기 위해 Redux로 결정!
참고 - velog.io/@cada/React-Redux-vs-Context-API
참고 - betterprogramming.pub/why-use-redux-when-we-have-context-api-95be70581148
(댓글까지 확인 요망)
'프로젝트들 > 크소' 카테고리의 다른 글
[그룹 스터디 프로젝트] 오늘 했고 할 일 (0503 ~ 0510) (0) | 2021.05.04 |
---|---|
[그룹 스터디 프로젝트] 네 번째 미팅 - 구현 In Progress! (0411) (0) | 2021.04.30 |
[그룹 스터디 프로젝트] 오늘 했고 할 일 (0426 ~ 0502) (0) | 2021.04.30 |
[그룹 스터디 프로젝트] 세 번째 미팅 - 구현 시작 (210404) (0) | 2021.04.30 |
[그룹 스터디 플젝] 두 번째 미팅 - 본격적 구현 전 방향 설정 (0401) (0) | 2021.04.24 |
댓글