카드 뒤집기

2023년 6월 17일 · 약 19분

arch-spatula

Cook-Book 많이 만듭니다

카드 뒤집기 구현은 생각보다 난이도 있었습니다. 하지만 재미있습니다.

카드 컴포넌트 view

카드를 뒤집는 동작을 완수해야 합니다.

오랜만에 position 속성을 활용했습니다. 스스로 약점을 또 찾았습니다.

또 특이한 속성이 있었습니다. backface-visibility입니다. 카드 뒷면을 숨기기 딱 좋은 속성이었습니다.

또 발견한 특이한 것은 상속 받은 스타일 컴포넌트의 제네릭을 정의할 수 있는 위치입니다.

const CardSize = styled.div`
  height: 19.5rem;
  width: 19.5rem;
`;

export const CardContainer = styled(CardSize)<{ active: boolean }>`
  position: absolute;
  left: 0;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
  box-shadow: 0 0.5rem 1rem rgba(0, 0, 0, 0.12);
  border-radius: 1rem;
  padding: 1.25rem;
  animation-duration: 0.3s;
  animation-fill-mode: forwards;
  backface-visibility: hidden;
`;

매개변수를 정의하는 다음에 제네릭을 정의한다는 점을 오늘 발견했습니다.

위 자료를 보고 만들 수 있게 되었습니다. 부모는 width, hight를 반드시 가져야 합니다. 그리고 자식은 값을 상속(100% or inherit)받으면 됩니다.

visibility는 예약어입니다.

Warning: Received false for a non-boolean attribute visibility

props 이름에 visibility를 visible로 이름을 바꾸니까 경고가 사라졌습니다.

react real world

이력서에 넣을 수 있을 정도로 정말 최소한의 기준이 react real world를 활용하라는 정보를 얻었습니다.

realworld github 레포

realworld 사이트

위 사이트보다 수준이 높으면 이력서에 넣어도 괜찮다는 것입니다.

하지만 검색 중에 Real World React도 발견했습니다. 여기서 유튜브 채널도 운영하고 있는데 네임드 개발자의 세션들도 있었습니다.

Real World React 유튜브

일단 마음의 안정을 취할 수 있을 것 같습니다. 더 난이도가 높고 퀄리티 높은 프로젝트를 만들 수 있을 것이라는 확신이 있습니다.

물론 강사님이 상당히 관대한 사람인 것 같습니다.

Fresh 1.2

Fresh 1.2 – welcoming a full-time maintainer, sharing state between islands, limited npm support, and more

아일랜드 아키텍쳐를 갖고 있는 프레임워크가 아일랜드간 상태 공유가 가능해진다는 업데이트가 있습니다. 저의 부족한 식견으로 봐서 프로토타입할 때 사용할 프레임워크로 엄청난 포텐셜을 갖고 있습니다.

verbatim

verbatim: 그대로

영어 아티클을 읽는데 모르는 단어가 나왔었습니다. 영타를 위한 영어 공부 말고 어휘력 공부도 심각하게 필요해보입니다. 엄청 기본 단어인데 모르고 있었습니다.

휴대폰 탭 정리

예비군에서 폰질을 많이 하면서 휴대폰 베터리를 너무 많이 그리고 너무 빨리 소모하기 시작했습니다. 물론 안드로이드 운영체제의 브라우저는 생각보다 효율적이라 큰 문제는 없을 것이지만 일단 정리하고 싶어졌습니다.

Image Carousel
FAQ/Accordion
Quote Generator
Shopping list
GitHub User Search
Video Player
BMI Calculator

컴포넌트 1개만 만드는 프로젝트를 진행하더라도 위 프로젝트들은 반드시 경험해야 하는 것들입니다.

그 외에 개인적으로 그래프 관련 컴포넌트까지 해봐야 한다고 생각합니다.

원티드 특강

저장소 만들기

git 기본이니까 다들 알아서 잘 만들도록 합니다.

fnm, volta, n로 node 버전을 관리할 것을 추천합니다.

라이브러리의 생산자가 될 것입니다. 지금까지 라이브러리의 소비자였다면 이제는 라이브러리의 생산자가 됩니다.

npm 환경 초기화

yarn init -y

스토리북을 설치합니다.

yarn storybook

vanilla-extract로 알아서 설치하도록 합니다.

타입스크립트 설정은 타입스크립트 언어보다 기본 중 기본입니다.

vanilla-extract를 선호할 이유느느 CSS-in-JS 스타일의 코드로 작성하는데 빌드타임에 CSS 컴파일해서 성능이 좋습니다.

또 타입스크립트이기 때문에 타입지정이 상당히 자연스럽습니다.

참고로 어디까지나 빌드타임에 CSS를 컴파일 할 뿐입니다.

양산형 프론트엔드들 대부분이 styled component를 활용하고 있습니다. 더 나쁘게 것만 든 프론트엔드들은 tail wind 사용하고 있습니다. 본인이 아주 익숙한 것 1개만 다루도록 합니다.

대부분 회사는 module css 활용하고 있습니다.

컴포넌트 구현

container presenter 패턴에서 props는 순서를 맞추도록 합니다. 부모의 컴포넌트의 props와 자식에게 전달할 props 순서를 맞추도록 합니다.

번들러 설치

이 예제에서는 rollup을 활용합니다.

yarn add rollup

vite과 웹팩은 엄청나게 다릅니다. 어디 이상한 것멋만 들고 건들리지 말고 역사와 전통의 웹팩을 고수합시다(물론 작년은 vite의 해였습니다.).

어떤 번들러든 엔트리포인트가 필요합니다.

esbuild로 성능 개선해보는 사람도 있습니다. 번들러에 해당하는 플러그인을 설치합니다.

플러그인이 필요한 이유는 build할 때 esbuild를 활용하는데 중간다리 역할로 필요합니다.

번들을 실행합니다.

번들이 동작한다는 사실을 잘 확인하고 다음 작업을 이어서 진행합니다.

peerDeps를 정의합니다.

peerDeps는 아주 기초 개념입니다. 상당히 간단합니다. 면접관 입장에서 양산형을 구분할 때 활용하기 좋습니다.

output을 지정합니다.

번들러는 input, output 중간에 plugin/loader 위주로 생각하면 됩니다.

npm 배포 아티클 좋은 자료가 상당히 많습니다.

역사와 전통의 dist 파일을 만들어서 거기에 담아도 됩니다.

output은 esm, cjs 각각 생성하도록 만듭니다.

main은 npm에 등록될 엔트리입니다.

버전 렌즈라는 플러그인을 활용하면 최신인지 확인할 수 있고 업데이트도 가능합니다.

https://rollupjs.org/tools/#peer-dependencies

peer dependencies는 위 공식 문서를 보고 알아서 잘 해결하도록 합니다.

npm 로그인

npm login

OTP를 적극적으로 활용하도록 합니다.

.gitignore 설정을 추가합니다.

npm에 키워드는 무조건 등록하도록 합니다. 개발의 작은 디테일은 기본 중 기본입니다.

폴더명 패키지명은 캐밥케이스가 컨벤션입니다. 이것 기본입니다. 그냥 다른 라이브러리만 조금봐도 볼 수 알 수 있는 것입니다.

prepack이라는 것이 추가되었습니다.

배포하는 것은 dist 파일을 배포하게 되는 것입니다.

npm publish 명령으로 올릴 수 있습니다.

vite과 웹팩은 본인의 취향 문제입니다.

리액트에서 컴포넌트를 만들 때는 최대한 원래 컴포넌트와 유사한 형태로 만듭니다. button에 text로 입력하지말고 children에 입력하는 스타일로 작성합니다.

패키지 설치

정상 동작을 확인합니다. 여기까지는 알파버전도 아닙니다.

원격 레포 연결

클론부터 따는 사람도 있습니다. 혼자 일할 때 몰래 그렇게 하고 대부분 검색 없이 로컬하고 원격하고 연결할 수 있습니다.

CI/CD는 크로마틱으로 할 것을 권장합니다. github action도 활용할 수 있습니다.

https://github.com/pocojang/cdd-storybook-wanted

docs page도 만들 수 있습니다. 레포 세팅에서 pages에 docs로 설정할 수 있습니다.

참고로 스토리북과 라이브러리용 번들러는 통일해줘야 합니다. 스토리북은 vite인데 만든 컴포넌트가 웹팩이면 docs에서 에러가 발생할 것입니다.

yml도 못 만지는 기초도 없는 사람들도 다룰 수 있게 제공해주는 것이 많습니다.

awesome readme에서 보고 배우도록 합니다. 또 npm readme example을 활용합니다.

마크다운도 시멘틱한 작성은 기본 중 기본입니다. h1이 1개인 것이 기본인 것처럼 마크다운에서도 동일하게 적용하도록 합니다.

시멘틱 버전은 아주 일반적인 컨벤션입니다. 그냥 마음이 편합니다. 버전이 특이한 경우도 있습니다. 페이스북 리액트 네이티브, 타입스크립트는 시멘틱 버전에 해당하지 않는 경우입니다.

문서화까지 배포하면 알파버전이 끝납니다.

다음 문제는 유지보수의 문제입니다.

타입스크립트 변환입니다. 배포전에 빌드과정이 바뀝니다. 바뀌는 것을 학습해야 합니다.

github action / Workflow로 자동 빌들를 작성해야 합니다.

릴리즈 문서도 자동생성하도록 만듭니다.
자동배포 트리거 시점을 지정하고 생성합니다.
커밋 메시지 보고 시멘틱 버전을 지정합니다.
커밋 메시지 보고 시멘틱 버번을 NPM 업데이트를 합니다.

이것은 기본입니다. 대부분 프론트엔드 할 줄 알고 있습니다. 양산형만 모릅니다. 이거 하는 신입이 대부분입니다.

https://twitter.com/willmcgugan/status/1423678688802058244

Absolutely. The thing about semver major version numbers are that they don't mean new stuff, they're a permanent reminder of how many times you got the API wrong. Semver doesn't mean MAJOR.MINOR.PATCH, it means FAILS.FEATURES.BUGS

- Will McGugan

커밋 컨벤션 중에서 앵귤러 커밋 컨벤션이 대부분 활용합니다.

커밋 메시지에서 작성한 정보를 활용해서 자동화합니다.

다음은 최적화를 해야 합니다.

CJS, ESM 빌드멸로 최적화 전략 빌드를 정해야 합니다.

깃 커밋 => 배포 시점 트리거 => NPM 업데이트 => 릴리즈 문서 생성 => 스토리북 페이지 배포가 되면 개발 사이클입니다.

Figma 수정 => JSON 생성 => 디자인 토큰 생성 => github action 트리거 => 레포에서 사용합니다.

디자인 토큰을 잘 제어하면 됩니다. 디자인 토큰은 디자이너와 커뮤니케이션할 때 hex 값으로 이야기하는 것처럼 활용하는 것입니다. 시멘틱 컬러에서 컬러 시리즈를 지정하는 것과 비슷합니다.

스토리북을 커스터마이징합니다.

크로마틱은 회귀테스트도 제공합니다. 스냅샷과 UI 테스트가 가능합니다.

Q&A

애용하는 디자인 패턴은 없습니다.
스토리북은 MSW랑 조합해서 사용하면 프론트엔드에게 괜찮은 인터랙션 테스트 도구입니다.
크로마틱은 좋은 기능이 많아서 추천합니다. 사이드 프로젝트에 적당합니다.
스토리북은 기능도 많지만 필요한 리소스가 많습니다. 프론트엔드 엔지니어의 숙련도가 높고 컴포넌트 레벨 개발이 많으면 유용합니다. 또 디자이너가 디자인 시스템 이해가 어느정도 있어야 합니다.
백엔드 개발자와 협업할 때 네트워크, API, http 등 프로토콜에 대한 학습을 잘 하도록 합니다. preflight, cache, option 모두 알아야 합니다. 실력 문제입니다.
- 욕심이 있다면 최소한 REST API 서버 만들어 봅시다. 여기가 한국이라고 Java를 고수할 필요는 없습니다.
yarn barry 사용할 때 pnp 모르면 곤란합니다.
런타임 에러는 심각한 에러입니다. API 오류는 주로 프론트엔드만 테스트를 하는 것은 아닙니다.
이력서에 추가할 만한 사이드 프로젝트는 react real world 정도 수준이 되어야 합니다. 정말 최소입니다. 이것도 못하면 곤란합니다.
뽑는 회사가 좋은 회사면 갑니다. 하지만 돈이 급하고 선택지가 없다면 SI 입사 전에는 좋좋소랑 조코딩 보고 가도록 합니다. 행운을 빕니다.
35살 이내면 괜찮습니다. 30대 비전공자 많습니다. 나이 많은 만큼 열심히 하는 사람 많습니다. 시작하기 늦은 나이는 없지만 돌아가면 늦은 나이가 됩니다.
상태코드 막날려서 200으로 모두 하나로 합치는 이상한 백엔드 있습니다. 하지만 공수가 많습니다.
회사가 한가하면 코드리뷰를 하면서 클린코드가 무엇인지 알려주면 됩니다.
난잡한 경우는 실력이 부족한 경우입니다. 고치지 못하는 경우 조언하는 것이 좋습니다.
null 병합 연산자(??)의 등장으로 의미가 퇴색했지만 undefined 대 null 중 undefined를 선호합니다. 특별한 설정이 필요 없습니다.
많은 회사가 아직도 프론트엔드 코드가 백엔드 내부에 있는 경우는 흔합니다. 백엔드가 직접 프론트를 보고 싶은 경우도 있습니다.
회고는 KTP, 4Ls, 5F, PMI를 추천합니다.
스토리북 맛보기를 한 것입니다. 이제는 조금더 고급스러운 자료를 봐도 이해가 잘 될 것입니다.

카드 컴포넌트 view​

visibility는 예약어입니다.​

react real world​

Fresh 1.2​

verbatim​

휴대폰 탭 정리​

원티드 특강​

Q&A​