1 / 24 (수)
팀 문화개인 성찰 및 목표1 / 25 (목) - 기술스택 논의
논의 주제
UI 라이브러리 → 미정
CSS - Tailwind
CSS 토론
성민
- tailwindcss
- 따로 진행 중인 프로젝트에서는 vanilla-extract
- emotion / styled-components는 런타임 시 영향을 미치기 때문에 다른 대체제를 찾아보는 것이 좋지 않을까! (대체제 → styleX, vanilla-extract, CSS-in-CSS 등)
수혁
- styled component
- tailwind 개인 프로젝트에 살짝 써봄
- 테일 윈드 저도 써보고 싶습니다. 개인 프로젝트 에서 사용할때와 비교해서, 스타일드보다 사용하기쉬웠습니다.
- → 팀 퍼포먼스
연경
- styled component
- → 팀 퍼포먼스
재준
- 테일윈드 + shadcn으로 디자인 적인 부분은 리소스 많이 절감.
1차팀 css 선정 과정
css 관련 성민님의 의견
시장이 큰 emotion, styled, tailwind, scss, sass, css module도 있고 제로런타임 표방 style X panda CSS
런타임에 영향을 미치는 라이브러리는 소거를 해봤다.
styledComponent emotion 두개 제외
남은 후보 tailwind scss sass css module styleX pandaCSS
CSS in CSS를 쓸 것이냐 atomic CSS를 쓸 것이냐. CSS in JS를 쓸 것이냐.
CSS in CSS
- css에서 사용되는 라이브러리 그 자체. styledComponent나 emotion처럼 런타임에 영향을 안미침. scss sass css module
- SCSS SASS 처럼 파일을 다루기 때문에 성능이 제일 좋다.
CSS in JS
- 얘는 JS 코드에서 CSS를 작성하기에 런타임 오버헤드가 발생할 수 있다는 문제.
- 이걸 쓰는 이유? → 개발자 도구 열었을 때 요소 탭에 class name이 어지러워지는데 이게 모듈 단위로 css를 제공 하기 위함이다.
- sass scss css module 쓰는 것보다 css in js를 쓰는게 더 의미가 있다. 클래스네임을 정할 필요도 없다.
- 모듈단위로 css를 제공하는 것의 장점 아래에 있음.
- HOME → ul → none → postList
- POST → ul → desc → postList
- 페이지 단위가 적을때에는 className이 안 겹칠 수 있는데 커질수록 그게 힘들 수 있다.
- 그렇게 되면 css in JS로 className을 난독화 해주면 위와같은 문제가 발생하지 않는다.
그래서 런타임 오버헤드가 있어도 이 장점을 고려하면 css in js가 선호가 된다.
atomic CSS
- 주문형 CSS
- flex, block, text-sm
tailwind같이…
좋은점 → css 자체가 작은 컴포넌트가 되고있는거네요
내부적으로는 css를 다루고 있어서 속도도 빠르고, 빌드 시 css코드로 모두 변환이 되기 때문에 런타임에 오버헤드가 발생하지 않는다는 장점이 있다. 작업속도도 빠르다.
className이 필요도 없거니와 작성했을 때 내용이 겹쳐도 상관이 없겠네요 얘는?
테일윈드가 지향하는 장점 - 문맥스위치가 발생하지 않는다.
- props → COLOR = ‘red’ | ‘blue’
bg-${COLOR}-500→ bg-red-500 | bg-blue-500
- bg-red-500 → background-color: ‘#ffff00’
- bg-red-500
- function getColor(color) {
return {
red: bg-red-500
blue: bg-blue-500
}
}
- 작업을 하다가 index.ts에서 컴포넌트 작업하다가 분리하는 경우에 style.ts를 또 따로 분리 안해도 된다.
- props → COLOR = ‘red’ | ‘blue’
- 컴포넌트를 분리함에 있어서 스타일까지 분리해야하는 불상사를 막아준다?
- build time에 css를 만들기 때문에 동적으로 변화하는 경우 힘들다… → 단점? 예시) 컴포넌트 만들다가 이 컴포넌트에 props로 값을 주고 props에 따라 스타일을 지정해주고 싶은 경우
color = primary | red | blue
우리가 tailwind를 정한 이유?
→ 제로런타임 css in JS는 나온지가 얼마 안되긴했어.
- npm 가보면 사용자 수가 다르다. 그만큼 css in JS보다는 tailwind쪽이 정보를 구하기가 더 쉽다.
그래서 우리가 css에서는 challenge보다는 안정성, 개발 속도 향상을 택하는게 나을 것 같다는 판단
UI 라이브러리 - shadcn
성민
- ui 라이브러리에 대한 개인적인 생각
- DEFAULT → UI 라이브러리 없이 직접 구현하는 것이 좋다. 컴포넌트 개발도 FE 개발자의 역할이기 때문에!
- UI 라이브러리를 고민해봐야 할 때?
- 개발 일정이 촉박하다.
- 디자이너가 없다.
- 위와 같은 점에서 UI 라이브러리 사용하는 거 나쁘지 않다고 생각합니다~
- 사용해보고 싶은 UI 라이브러리
- 최근에 shadcn/ui 되게 깔끔하고 커스텀도 용이한 것 같아서 언제 한 번 사용해봐야겠다 노려보고 있던 중이었습니다ㅎㅎ
- chakra/ui도 개인적으로 좋아하는 라이브러리입니다
- 사실 뭘 쓰든 상관 없어요ㅋㅋㅋ
재준 -
저는 디자인 시스템의 중요도를 무시하는건 아니지만 우리 일정을 생각하면 그 시간을 아껴서 Next를 공부한다거나 좀 더 중요한 기술들을 공부하는게 좋아보입니다! 1차 프로젝트를 생각해보면 2달이 긴 시간은 아닌 것 같아서요 ㅠㅠ
다만 이렇게 하다보니 기술부채가 쌓이는 것 같아서 만약 사용하지 않는 의견으로 모아져도 기꺼이 어차피 해야할 공부라고 생각하고 할 것 같습니다!
그래서 가장 중요한게 일정을 산정할 때 우리가 사용자를 모으는 경험을 위해
1차 배포를 빠르게 하고 (진짜 대충 뼈다귀랑 기능만ㄴ 있음)
2차 (실제로 쓸만해짐)
3차 이후 배포까지 릴리즈를 계속 하는걸 목표로 할 때 ui 라이브러리를 사용한 경우와 사용하지 않은 경우 속도차이가 얼마나 날지 알아야 한다고 생각합니다.
사용을 하게 된다면 저희 팀이 shadcn을 사용한 이유 -
shadcn
- tailwind 사용법에 대한 레퍼런스를 받을 수 있다
- tailwind와 궁합이 좋다.
- 다른 라이브러리와 다르게 쉽게 커스텀이 가능하다.
- 모든 컴포넌트를 다운받지 않아도 되기 때문에 용량 부담이 적다.
- 프로젝트의 아이덴티티와 잘 맞는다. .
- 제일 예쁘다
다른 대중적인 Material UI 도 있고 차크라도 있지만, tailwind를 사용하기로 한 시점에서는 shadcn이 가장 궁합이 좋은 선택이라고 생각되었습니다.
수혁
- 저는 전에 있던 팀원분이 디자인 시스템을 거의 구축해주셔서, 편하게했는데, 만약 그럴 시간과 여유가 없다면 쓰는것이 좋다고생각합니다.!
- 생각해보니 shadcn 으로 참조해서 디자인 시스템을 구현했던것 같네요!
- 미리 shadcn 을쓰고 시간이 남으면 이전 하는 방식은 어려울까요!??
연경
- UI 라이브러리 없이 내부 구현을 고민하면서 배우는 내용도 있다고 생각합니다.
- 다만 디자이너가 없을 경우, 일관된 스타일에 대해서는 논의하는 시간이 필요하다고 생각합니다.
연경 - 학습용으로 프젝을 진행할거라면 제외하는게 좋을까 라는 의문
성민 - UI 라이브러리 사용에 대해 조심해야한다고 생각. 포폴로 제출을 했을 때 포폴의 컴포넌트 대부분이 UI 라이브러리의 도움을 받았다면 좋진 않을 것 같다는 생각이 든다. 멘토님께 질문을 한번 드려보는것은 어떨까 면접관님이 어떻게 보실지 여쭤보는것도 좋아보인다.
연경님 목표는 MAUㅇ였지만 실제로 기획을 보고 결정을 하긴 해야한다.
패키지 매니저 - pnpm
pnpm 패키지 매니저 결정
프로젝트 기간 내 코어타임 35일.
재준 - 사실 패키지매니저가 어떤 이유로 중요한지 크게 와닿지 않는다(이론과 체감부족 이슈인듯)
yarn과 npm이 익숙하긴 하지만 성민님 말씀을 들어보면 pnpm을 사용하지 않을 이유가 없어보인다.
성민 - 유령 의존성 겪은적이 있다. import를 하려고 자동완성을 했는데 내가 설치한 적 없는 패키지가 떴다.
styledcomponent에서 emotion을 의존성으로 갖고있다고 예를 들어보자. 근데 둘 다 똑같이 styled라는 함수를 사용하는데, styled가 StyledComponent랑 emotion둘다 뜨는거다. 어 이게 왜 둘 다 뜨지? 심지어 난 emotion만 설치했는데 둘 다 뜨고 둘 다 실행되네?
→ 의도하지 않은 결과가 발생할 수 있다. 불확실성 통제를 위해 필요한 문제이다.
수혁
- npm 에 비해 pnpm 이빠르다고 알고있다.
- 그렇지만, 실제 이번 프로젝트에서 속도가 중요할지는 의문이다. (설치할때 [빌드] 할때 엄청 시간이 걸리면 문제가될수도있지만, 그렇게 차이날까 궁금합니다.?!)
- 성민님이 말씀하신 유령 의존성 문제도, 이번 프로젝트에서는 중요할지?? 살짝 의문입니다.. (잘 모르기도해서,, 아닐수도있습니다.)
- npm , pnpm 의 커멘드라인 문법이 차이가 별로 없다면 혹은, 배우기 쉽다면 그런 문제점을 해결해줄수있다는 의의를 두고 사용해도 좋을것 같습니다.!
연경
- 지난 프로젝트 npm ,
yarn
- npm이 상대적으로 yarn에 비해 갖는 문제점도 많이 개선되었다는 것으로 알고있습니다.
- 맞아맞아…마자마자….
TS vs JS → TS
실수 방지, 편리한 기능, 러닝커브 등 논의
성민
- React, Next 등과 호환이 안정적인가? - Yes
- 배우기 쉬운가? - No
- 러닝 커브가 큰 편인 것 같음
- 코드를 간결하게 작성할 수 있는가? - No(?)
- 타입 관련 코드가 추가되면 아무래도 코드가 더 길어지고 장황해질 수 있다는 문제가 있음
- 최근에 엄청 이슈가 됐던 사건인 것 같네요ㅋㅋㅋ
- turbo에서 TS를 제거하고 머지해버린 사건
- 제가 잘못 링크를 걸었네요.
- vercel이 인수한 turbo가 아니라 다른 녀석이었어요…
- 3줄 요약
- 본인은 원래 TS를 좋아한 적이 없다.
- JS만 사용하면 컴파일 단계 없이 브라우저에서 직접 실행할 수 있다.
- 3줄 채우기
- 참고1) ECMA에서 TS의 대체제인 ts annotation?을 표준으로 합치는 것에 대해 논의 중이라고 하네요
- 그렇게 되면 미래에는 ts가 결국 필요 없어질지도?..
- 참고2) svelte에서도 ts를 걷어냈다고 합니다ㅋㅋㅋㅋ
재준 -
- 구현할 때 타입에러가 많아서 슬프고 답답하고 속상하지만 막상 에러를 해결한 경우에 예상치 못한 버그는 줄어드는 것 같다. (예상치 못한 버그가 생겼다면 그것은 다른쪽에서 타입을 건드렸기 때문으로 특정이 가능했음)
- 근데 아직도 러닝커브에 놓여있는 느낌임. 구현에서 타입지정으로 인한 에러가 상당히 시간을 소모함.
- TS는 대규모 프로젝트일 수록 불확실성을 더 효율적으로 줄여주는 경향이 있다고 생각함.
- 사실 4명이서 진행하는 이 프로젝트에선 그정도의 효율을 기대할 수 없을지도 모른다.
- 그럼에도 불구하고 현실적으로 점유율이 큰 기술임을 무시할 수는 없음.
- 결국 굳이 쓰지 않고 진행해야할 이유가 없다
연경
- 사용되는 타입이 명확하기 때문에, 실수 방지가 가능하다고 생각합니다.
- 컴포넌트 props로 작성되지 않은 내용들을 가려내어 오류를 방지합니다.
- 다만 복잡하게 제네릭을 사용하는 경우는 익숙하지 않습니다.
- initialState를 늘 고민하게 되네요
수혁
- 지난 프로젝트 경험에 비춰볼때 , 라이브러리자체 에서도 타입 스크립트를 사용함에있어서 편리한 경우가 많았습니다.
- 리덕스 툴킷을 사용 했을때 타입을 지정하면 어떤 타입인지 쉽게 알수있고, 자동완성 이 지원됨을 확인했습니다.
- 하지만 잘 사용하는데 있어서는 자세히 알아보고하는게 좋다고생각이듭니다.
- api 응답 타입을 미리 지정하면 편리한 점 이 많았다. (응답 모델의 속성을 호버하기만 하면 바로알수있다.)
React
러닝커브, 동작원리 논의
성민
- 포트폴리오에 쓰기에 제대로 설명할 수 없다면, 안 하느니만 못하다.
- 최근 트렌드는 next, 말 할 기회 자체가 많아진다.
- 안전성 : 리액트,
도입에 장단점이 있고 나름대로 합당한 이유가 있으면 될 것 같다.
본인이 선택하는 기준은 안정성을 선택한다. 다 같이 알고있다보니 리액트를 선택한다.
전략적으로 행동하거나 새로운 도전을 채택한다면 Next를 선택한다.
Next는 깊게 배우지 않았다. 러닝커브가 발생할 수 밖에 없다. 독이 될 수도 있다.
CSR과 SSR의 차이로 보면 되나?
이미지를 최적화 해서 제공해주는 것도 있고,
CSR과 SSR이 프로젝트의 어떤 특성에 따라서 고려가 될 수 있을지?
SSR - 서버에서 html을 만들어서 넘겨주는거다. 언뜻 보기엔 빠르고 좋아보이는데 결국 동적으로 많이 바뀌는 페이지가 존재하면 서버에서 html을 만드는 시간이 증가해서 비용이 늘어날 수도 있다. 페이지가 어떻게 구성되느냐가 큰 차이일 것이라고 생각이 된다.
수혁
- 원래는 React 대신 Next를 사용할 생각이었음
- 지금 생각하기엔? Next 러닝 커브가 조금 있긴 함
- 한 번도 사용하보지 않은 입장에서는 React를 사용하는 게 포포레 올릴 때 완성도를 높일 수 있지 않나?
- 만약 Next를 사용하면? 그래도 열심히 하면 따라 잡을 수 있지 않을까?
- 아직 결정하기에는 무리가 있는데, 마음의 기울기를 따져보자면 React!
연경
- 리액트와 함께 넥스트를 같이 배워봤지만, 제대로 배운진못했다.
- 기억나는 내용이 거의 없기 때문에, 넥스트를 한다면 문서를 다시 보고 차이점을 살펴봐야겠습니다.
이건 다같이 한 번 조사해보면 좋을 거 같아요~
TanstackQuery + Axios
캐싱, 서버상태와 클라이언트 상태분리 ,선언적 코드등
리액트를 쓰냐 next를 쓰냐에 따라 달라질 수 잇다.
next router 버전이 달라지면서 fetch 관련 코드를 다 갈아엎었다.
Next의 기존 fetch함수
기존 - 캐싱도 없고 res req만 가능했는데
변경점 → 캐싱도 지원, ssr도 지원.
다만 안정성이 의문이긴 한데 고려해볼 가치는 있다.
Next를 사용하되 fetch를 사용하지 않을수도 있다. 그래서 소거 해보자.
axios를 사용하는 이유는 뭐냐.
fetch시 json으로 data값 변환할 때 default옵션 설정이 힘들고
url에 params를 끼워서 보내야하는게 작업하기 귀찮은 경험인데,
axios를 사용하면 url과 data를 구분해서 보낼 수 있고
인터셉터를 사용해서 쿠키나 토큰 등을 넣어서 보내줄 수 잇다.
요청에 대한 응답도 가로채서 응답을 parsing해주는 것도 가능하다.
tanstack query는
리액트 사용시 상태라는게 상당히 중요함. 렌더링의 비용에 영향을 미치는.
상태가 매우 중요한데 서버상태, 클라이언트 상태가 있다.
클라이언트 상태 → 클라이언트에서만 동작하는 상태. 다크모드
서버상태 → 유저정보 같은 예시가 있음.
상태를 구분하는게 좋다. >>>> 왜?
리액트만 사용할 때에는 전역상태관리로 전부 클라이언트 상태로 관리했다.
이렇게 하니까 상태의 구분이 없어졌고, 서버상태가 변경이 되었을 때 클라이언트의 상태도 변경해줘야하는 문제가 발생햇따 >>>> 렌더링을 새로 해줘야함
트래픽이 많은 경우 서버 상태 변경시에 맞춰 계속 클라이언트 상태가 같이 변경되고 렌더링이 발생했다.
이를 해결하기 위해 나온게 리액트 쿼리이다. redux나 recoil처럼 전역으로 쓰는게 아니라
instance를 생성해서 context처럼 provider로 한번 감싸주게 되는데,
내가 불러온 서버 상태를 다 갖고 있게되기 때문에 캐싱을 할 수 있다.
서버상태가 변경되지 않은 경우 이 페이지에 다시 접속하는 경우 api콜을 호출하는 상황을 줄여준다.
로딩값이나 에러값이나 다 넘겨주기 때문에 한번에 선언적으로 처리해주는 코드 작성 가능.
막상 클라이언트 상태 관리는 우리가 크게 사용할 일이 없다. 당장 다크모드 말고 뭐가있나 싶긴해.
서버상태를 좀 더 관리하게 되는데 이를 용이하게 해줌. 캐싱기능도 불필요한 api호출을 줄여주기 때문에 사용자 경험개선과 동시에 비용을 줄여주는 중요한 요소인 것 같다.
SWR?
잘 모름. tanstack query랑 swr의 사용은 취향차이라고 들은 적이 있다.
여기는 좀 더 알아봐야할 듯
next를 사용하게 되면 swr을 고려해보면 좋을듯
버셀에서 지원을 하는 거라면 버셀에서 지원하는 next와 궁합이 좋지 않을까?
ㅇㅋㅇㅋ 요정도.
1 / 26 (금) - 컨벤션 논의
깃 컨벤션
재준님 2차팀 깃 컨벤션 기반 논의 완료
이슈 컨벤션
## 🔨 설명 작업할 내용에 대해 상세하게 설명해주세요. ## 📑 완료 조건 어디까지 개발할 것인지 목표에 대해 설명해주세요.
template에 맞게 issue를 작성해주세요. 기존에 만들어둔 template을 사용하면 됩니다.😀
브랜치 이름 컨벤션
작업 단위마다 이슈를 생성하고, 브랜치 이름에 작업 설명과 이슈 이름을 남깁니다.
이슈 단위 브랜치
이슈마다 브랜치가 1개 있는 셈입니다.
- branch(브랜치명은 issue 제목)
feature/#이슈번호/이슈 제목 fix/#이슈번호/ test/#이슈번호/ refactor/#이슈번호/ ex) feature/#11/make-home-page(이슈 제목)
issue 만들고, 그 issue에 맞는 번호를 확인한 뒤, 이 번호에 따라 branch 생성.
branch 이름은 다음과 같은 규칙으로 작성해주세요.
merge가 완료되어 작업이 끝났다면 반드시 branch를 삭제해주세요. 충돌은 본인이 확인해서 해결 부탁드립니다.
merge가 완료되면 issue도 close 부탁드립니다.
fix, refactor 또한 issue 작성 후, issue 제목에 맞게 브랜치 생성해서 작업 부탁드립니다.
git commit message convention
- commit(유의미한 작업 별로 쪼개서 자주 커밋 부탁드립니다)
Feat: commit 내용 ex) Feat: 홈페이지 컴포넌트 구현 -- 경우에 따라서 Body 작성이 필요할 수도 있습니다. Body도 잘 작성해주면 좋을 것 같아요~
해당 이슈와 관련없는 커밋은 하지 않습니다. 관련없는 커밋이 필요하다면 새로운 이슈를 작성하고 브랜치를 변경해주세요. 첫 글자는 대문자로 적어주세요
- Init → 프로젝트 생성
- Feat → 새로운 기능을 개발한 경우
- Fix → 버그 수정(코드 수정은 포함하지 않음)
- Refactor → 새로운 기능을 개발하지 않으면서 코드를 수정하는 경우
- Docs → 문서를 수정하는 경우
- Style → UI, Style 변경하는 경우
- Test → 테스트 코드를 작성하는 경우 (Storybook 포함)
- Chore → 패키지 설치?
- 자잘한 작업들, 주석 삭제 등
- 중요 로직 관련 변경이 아닌 자잘한 작업들
- Build → 패키지 설치
- Perf → 성능 향상을 한 경우
- Ci → ci/cd, actions
- storybook 배포
PR title convention
다음과 같은 형식으로 pr 제목을 작성해주세요.
[#이슈번호] Keyword: 구현 내용 간략히 ex) [#11] Feat: make-home-page 컴포넌트 구현
Merge 전략
과욕은 금물
과욕인가요?아닌가요?
- 작업 브랜치 > dev 브랜치 >
squash> main
- 작업 브랜치 > main
- 그 외
공부하고 정합시다!
멘토님) main브랜치 하나만 가지고 전략을 세워보는것도 좋아보인다. (trunkbased)
만약에 새로운 시도를 하고싶지 않다면 기존의 편한 방식대로 해도 되고 (그 리소스를 다른 기술에 투자)
- git 브랜치
- main → 릴리즈랑 같이 맞춰주는 거?
- develop → 피처를 디벨롭에다 다 머지한다 → 일정 기간이 지나면 디벨롭을 릴리즈로 옮긴다 → 그게 배포 버전이 되는 것
- release → 릴리즈 전용 브랜치
- hotfix → 프로덕션 환경에서 버그가 발생한 걸 잡은 경우
- feature → 기능 개발하는 브랜치
- 제일 유명
- 웹 개발 적합하지 않음
- github 브랜치
- main 브랜치가 곧 릴리즈
- feature → 개발이 완료되면 main에 머지하고 그걸 바로 release
- 간소화, 적용하기 쉽고, 작업 속도도 빠름
- 중간 점검 PR 올려요
- pR 리뷰 → 바로바로 고치고
- 문제가 있는 건 git 브랜치에 비해 main 안정성 떨어짐
- 테스트를 잘 해야 된다.
- gitlab 브랜치
- git / github 사이
- main
- feature → 기능 개발 후 → main에 머지
- release → 메인에껄 그대로 가져옴 → 배포
- trunkbased 확실히 모르겠음
당근 전략
main branch 기준으로 alpha beta나간다
전체 flow는 메인에서 나가고
feature branch에서 작업을 진행
- 작업 브랜치 >
squash> dev 브랜치 >merge> main → gitlab
rebase사용여부 → rebase merge는 안하고,
(당근처럼 dev없이 하나의 main브랜치를 두고 있을 때) 내가 feature브랜치 분기를 했는데 다른사람이 main에 merge를 해버린 경우에, 그사람의 작업변경 사항(package.json) 충돌 막기 위해서 사용함 (feature branch rebase 후 squash merge)
rebase merge는 거의 안써요 22
개발 컨벤션 - 토스트 ui 기반
안티패턴 논의완료 (토스트 ui 기반) → 요런건 Lint 룰로 알지 않아도 되도록 하자.
1 / 29 (월)
백엔드 와 기획 전 논의 해보면 좋을 주제
- 보안
- git
PR 이슈 사용여부
- 일정
개인 시간 정하기- 일정 산정. 기획 기간, 개발 기간, QA기간
- 기술스택
패키지 매니저Next, TS 여부- 상태관리 라이브러리
- 유효성 검사
- msw (api mocking library) 사용
- Storybook 사용 여부
CSS 라이브러리- UI 라이브러리
논의 보류 목록 (토스 ui 안티패턴)
불필요한 레이아웃을 발생시키지 않는다 - 성민님 께서 링크 주신다고 하심 → 유튜브 링크 드릴게요
with()를 사용하지 않는다 - 알아보면 좋을듯함 → 알아보면 좋을 거 같음담주 화욜 (커피챗) 질문
- rebase vs pull
ui라이브러리 사용여부?
→ 어설프게 만드는 (되는대로 만들거면) 컴포넌트는 하지말고 차라리 라이브러리 써라
함수를 만드는건데 규모가 일정하지 않고 애매하게 할거면 차라리 라이브러리 써라.
제대로 컴포넌트를 만드는것도 사실 생각보다 어렵다.
‘돌아가게만 만드는것이 중요한건 아닌거같다’
둘은 사용경험있고 둘은 없을 때 리스크를 줄이면서 경험이 없는 사람들이 최대 퍼포먼스를 뽑을 수 있는 방법이 있을까?
→ 테일윈드 써본사람이 컴포넌트 쫙 뽑아내서 이름만 알려줘
단, 설계를 매우 잘해야한다.
기획
뭔가를 만든다 - 현실의 문제를 해결한다.
유저가 없으면 데이터 쪼가리다.
학습하는 공간이다.
자기 실력을 잘 보여줄 수 있는 제품을 선택하는것도 전략이 될 수도 있다.
TS쓰면 유틸리티타입이나 제네릭 오버로딩 쓸 수 있냐 이런거.