일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 기초
- 쓰레드
- mock service worker
- thread
- 최적화
- Concurrent Mode
- 개발자
- 리액트
- front-end mocking
- 컴포넌트
- 리액트네이티브
- Critical Rendering Path
- Babel
- react-native
- CSS-in-JS
- 리액트쿼리
- 동기
- link
- JavaScript
- vanilla-extract
- React
- react-query
- 비동기
- 자바스크립트
- Cache
- next hydration
- async
- 캐쉬
- react server component
- SWC
- MSW
- amplify
- styled-component
- Basic
- 목킹
- sprinkles
- 기본
- mockoon
- next.js
- 아키텍처
- Today
- Total
목록styled-component (3)
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..

next.js는 초기 렌더링만 서버가 담당 ( SSR ) 이후 CSR로 동작을 한다. 첫 화면 로딩시에는 SSR로 렌더링하면서 오류가 발생하지 않지만, CSR로 렌더링하면서, 서버에서 클래스명과 클라이언트에서 클래스명이 달려져서 생기는 오류이다. 같은 Header를 home 쪽에서 ssr로 렌더링하고 다른 페이지 이동후 새로고침하면 기존에 있는 header( ssr로 내려온 header ) 와 페이지 이동된 후 header (csr로 그려준 header )의 클래스 해쉬 값이 달라 위와 같은 에러 해결방법 babel-plugin 설치 npm i babel-plugin-styled-components 프로젝트 루트 경로에 .babelrc 파일 생성 이미 존재하면 해당 값 기입 { "presets": ["n..