| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
Tags
- 목킹
- 리액트네이티브
- Basic
- Concurrent Mode
- React
- 최적화
- JavaScript
- next.js
- 동기
- Cache
- 캐쉬
- 비동기
- CSS-in-JS
- sprinkles
- async
- react server component
- SWC
- Babel
- 기본
- 아키텍처
- styled-component
- vanilla-extract
- Critical Rendering Path
- 리액트
- thread
- mockoon
- 기초
- 개발자
- link
- react-query
- mock service worker
- 리액트쿼리
- amplify
- 컴포넌트
- MSW
- front-end mocking
- 쓰레드
- 자바스크립트
- react-native
- next hydration
Archives
- Today
- Total
목록장점 (1)
Don’t worry about failures
css-in-js를 떠나 보내야하나?
해당 글은 다른 아티클을 보면서, 편향된 개인적인 생각일 수 있다. 이전 사이드프로젝트를 리팩토링하는 새로운 나만의 프로젝트를 하면서 고민되는 사항이 생겼다. 내가 평소 즐겨쓰던 Styled-component를 현재의 프런트엔드 개발 흐름과 잘어울리까? 에대한 고민이다. 일단, 내가 왜 Styled-component를 즐겨썼을까? 개발자 경험이 가장 크다고 생각했다. 위의 코드를 봤을 때 개인적으로는 div로 표현하기보다는 Container으로 표현하는게 내 눈에는 더 파악하가기가 쉽다고 생각했다. 이 외에도 다른 장점들을 살펴보면, 1. 지역 스코프 스타일드 컴포넌트의 동작 방식을 보면, styled.div에 대한 고유 ID와 style을 적용한 css를 기반으로 해시를 생성하고 생성된 값은 clas..
React
2024. 4. 22. 12:37