23.02.12

#State

함수 내에 선언된 변수처럼 컴포넌트 안에서 관리

• 사용자 작업 또는 네트워크 변경에 따라 state를 수정할 수 있다
• 객체의 상태가 바뀔 때마다 리액트는 컴포넌트를 브라우저에 다시 렌더링한다
• state 객체는 생성자에서 초기화된다
• state 객체는 여러 속성을 저장할 수 있다
• this.setState()는 state 객체의 값을 저장하는 데 쓰인다
• setState()는 새 state와 이전 state 사이의 얕은 병합을 수행한다

 

#Props

함수매개변수처럼 컴포넌트에 전달한다.

• 기본적으로 Component에 원하는 값을 넘겨줄 때 사용하며 넘겨줄 수 있는 값은 변수, 함수, 객체, 배열 등 JavaScript의 요소라면 제한이 없다.
• 주로 Component의 ‘재사용’을 위하여 사용한다.
• props는 읽기 전용이라서 값을 변경하면 안 된다.
• 변경한다고 해서 에러가 발생되는 것은 아니지만 리액트가 props의 변경을 감지하고 재 랜더링 하는데 문제를 야기할 수 있다.
• props 값을 받고 가공하고 싶다면 새로운 변수를 생성하고 props 값을 복제해서 사용한다.

 

#리렌더링 발생 조건

• Props가 변경되었을 때
• State가 변경되었을 때
• forceUpdate() 를 실행하였을 때
• 부모 컴포넌트가 렌더링되었을 때

 

#본격적인 개발일지

이번주는 다른것보다는 스타일에 대해 공부를 하게된 주인듯 하다.

 

기존에 내가 사용햇던 css의 문제점은 다음과 같다.

• Global namespace: 모든 스타일이 global에 선언되어 중복되지 않는 class 이름을 적용해야 하는 문제
• Dependencies: css 간의 의존관계를 관리하기 힘든 문제
• Dead Code Elimination: 기능 추가, 변경, 삭제 과정에서 불필요한 CSS를 제거하기 어려운 문제
• Minification: 클래스 이름의 최소화 문제
• Sharing Constants: JS 코드와 상태 값을 공유할 수 없는 문제
• Non-deterministic Resolution: CSS 로드 순서에 따라 스타일 우선 순위가 달라지는 문제
• Isolation: CSS와 JS가 분리된 탓에 상속에 따른 격리가 어려운 문제

여기서 중요한건 중복되지 않는 css이름을 사용해야한다? js코드와 상태값을 공유가 안된다 정도?

 

그레서 나온게 css in css vs css in js 가 되는거 같다.

그중에 css in css 즉 scss, sass 설명은 아래 대충 적어놓자면

• SASS와 SCSS는 CSS를 편리하게 사용할 수 있도록 하며 추가 기능 또한 있는 확장판 스크립트 언어
• SASS, SCSS에서 기존의 CSS의 기능 부재 단점을 보완한 다양한 기능 추가
• SASS는 들여 쓰기+줄 바꿈 형식, SCSS는 중괄호+세미콜론 형식
• 전 세계적으로 SCSS 사용자 수, SCSS를 활용한 라이브러리&프레임워크 수가 SASS 보다 더 많음
• SASS보다 SCSS가 CSS와의 호환성이 더 좋음

이렇다고 해서 아 개발하면 이제 scss 나 sass를 배우는구나 개발자 하시는 분들이 그리 좋다고 난리를 햇엇으니 라고 생각햇는데 요즘 css in js 즉 styled-components를 사용한다고 해서 그걸 배우게 되는.... ㅠ 장점? 으로는 다음과 같다고 한다.

• 컴포넌트로 생각하기— 더이상 스타일시트의 묶음을 유지보수 할 필요가 없습니다. CSS-in-JS는 CSS 모델을 문서 레벨이 아니라 컴포넌트 레벨로 추상화
• CSS-in-JS는 JavaScript 환경을 최대한 활용하여 CSS를 향상
• 스코프가 있는 선택자—CSS는 하나의 전역 네임스페이스만 있습니다. 복잡한 애플리케이션 내에서 선택자 충돌을 피할 수 없다. BEM과 같은 네이밍 컨벤션은 한 프로젝트 내에서는 도움이 되지만, 서드파티 코드를 통합할 때는 도움이 되지 않다. JSS는 JSON으로 표현된 것을 CSS로 컴파일 할 때, 기본적으로 고유한 이름을 생성한다.
• 코드 공유—JavaScript와 CSS사이에 상수와 함수를 쉽게 공유할 수 있다.

여기서 중요하게 생각이 되는게 컴포넌트 레벨로 추상화 할수 있다 코드공유가 가능하다 이정도?

확실히 메리트는 있다고 생각이 드는데 아직은 적응을 하기가 힘들어서 뭔가 굳이 써야하나 라는 생각이 들게 하는 방식이라고 생각된다 아직까지는 ... 그레서 더찾아 봣는데 이거 싸움 많다고...

그리고 최종적으로 찾은 내용이 뭐가 더 좋고 뭐가 더 않좋다 이런 생각하지 말라는거였다.

그냥 언제 어떻게 누굴대상으로 쓸것인가 에 차이점을 두고 사용하면된다고... ㅠ

 

컴포넌트 위주의 프레임워크 

CSS-in-CSS : 사용하지 않는 CSS 스타일 요소까지 로딩하기 때문에 비효율적이다. 

CSS-in-JS : 필요한 컴포넌트 페이지의 CSS 스타일 요소만 로딩한다. 

 

인터렉티브한 웹 사이트

CSS-in-CSS : 랜더링할 때 모든 CSS 스타일 요소를 로딩하기 때문에 컴포넌트 상태가 변하더라도 바로 적용이 가능하다.

CSS-in-JS : 상태 변경으로 인한 랜더링 때마다 JS 파일 내의 CSS 코드를 로딩 (파싱 등)해야하기 때문에 성능이 떨어질 수 있다. (컴포넌트 내 인터렉티브한 변화는 다를 수 있다)

 

그냥 사이트마다 다르게 사용하는게 정답인거 같다.....

 

참고 사이트

https://d0gf00t.tistory.com/22 

[번역] CSS-in-JS에 관해 알아야 할 모든 것

https://seizemymoment.tistory.com/145

[CSS] CSS를 대체할 CSS in CSS와 CSS in JS에 대해 알아보자 (CSS Module , SCSS 등)