일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- front-end mocking
- styled-component
- Babel
- 자바스크립트
- 리액트
- 리액트네이티브
- Cache
- 아키텍처
- 비동기
- 쓰레드
- JavaScript
- 최적화
- 리액트쿼리
- 개발자
- link
- thread
- async
- 컴포넌트
- mockoon
- react-native
- vanilla-extract
- Basic
- CSS-in-JS
- MSW
- 기초
- React
- react server component
- 기본
- 목킹
- next hydration
- 동기
- amplify
- next.js
- Concurrent Mode
- react-query
- mock service worker
- SWC
- sprinkles
- Critical Rendering Path
- 캐쉬
- Today
- Total
목록CSS-in-JS (2)
Don’t worry about failures

사이드 프로젝트 리펙토링 과정에서 마이그레이션 작업이 하나가 추가 됐다. styled-component에서 vanilla-extract처음에는 styled-component가 개발경험에 있어 개인적으로 좋다고 생각했다. 컴포넌트로 표현되는 것과 javascript과 함께 컨트롤를 할 수 있다는게 좋다고 생각했기 때문에 사용했었다. 하지만 다른 측면으로도 생각을 해보았다. styled-component의 경우 동작하는 방식이 runtime 때 동적으로 스타일이 적용이 된다. 이는 csr과 어울리는 방식이다. 하지만 지금 사용하고자 하는 Next.js라는 프레임워크는 ssr, rsc와 같이 서버 사이드에서 렌더링을 진행하고자한다. 이를 보았을 때 동작하는 방식이 차이가 있다고 생각했다. styled-comp..

해당 글은 다른 아티클을 보면서, 편향된 개인적인 생각일 수 있다. 이전 사이드프로젝트를 리팩토링하는 새로운 나만의 프로젝트를 하면서 고민되는 사항이 생겼다. 내가 평소 즐겨쓰던 Styled-component를 현재의 프런트엔드 개발 흐름과 잘어울리까? 에대한 고민이다. 일단, 내가 왜 Styled-component를 즐겨썼을까? 개발자 경험이 가장 크다고 생각했다. 위의 코드를 봤을 때 개인적으로는 div로 표현하기보다는 Container으로 표현하는게 내 눈에는 더 파악하가기가 쉽다고 생각했다. 이 외에도 다른 장점들을 살펴보면, 1. 지역 스코프 스타일드 컴포넌트의 동작 방식을 보면, styled.div에 대한 고유 ID와 style을 적용한 css를 기반으로 해시를 생성하고 생성된 값은 clas..