Skip to content

Latest commit

 

History

History
130 lines (108 loc) · 8.65 KB

toc.md

File metadata and controls

130 lines (108 loc) · 8.65 KB
  1. 시작

지금부터 제가 전달할 내용은 react, 그리고 next에서 여러 스타일링 방법을 경험했고, 그 경험에 대해 개인적으로 분석한 내용이다. 이 내용들이 새로 프로젝트를 시작할 때 어떤 스타일링 설계 방법을 선택해야 하는지, 지금 우리 프로젝트는 좋은 설계 방법인지에 대해 조금의 도움이라도 되는 마음으로 내용을 시작한다.

react에서 주로 사용되는 스타일링 방식 2가지. scss와 css in js 라 불리는 styled-components가 대표적. 먼저 scss에 대해 js의 기능처럼 쓸 수 있는 예제들을 간단히 보겠다.

  1. scss의 기본 사용 예제. 1.1 mixin,extend 1.2 배열 list, map 1.3 반복문 for, each 1.4 조건문 if

  2. scss의 그 외 기능들 2.1 spread operator 2.2 unquote, quote 2.3 unique-id() 2.3.1 unique-id()로 만들 수 있는 기능

    • button class명 unique-화 하기 [출처 허락 필요]

  3. styled의 기본 사용 예제. 3.1 props 번외: emotion 훑어보기

  4. scss와 styled의 기본 비교 4.1 코드 비교 4.2 scss의 단점 4.2.1 중복된 class naming 4.2.2 class naming으로 인한 모듈화의 고민 4.2.3 다양한 상태에 대한 대처 힘듬. 4.3 styled의 단점 4.3.1 해쉬처리된 클래스명으로 인한 추적의 어려움 4.3.2 ui의 상태 변경 시 rerendering 4.3.3 선언된 styled가 많을 수록, import 하는 styled도 많다. 4.3.4 css보다 느린 렌더 속도.

  5. 서로의 단점을 보완해보자. (기본형) 5.1 scss의 단점을 styled에서 보완하기 5.1.1 다양한 상태에 대한 대처 -> 상태에 대한 theme를 props로 받아사용할 수 있는 styled로 만들자. 5.1.2 중복된 class naming -> 해쉬 - 뇌피셜로 만드는 고유 클래스 5.2 styled의 단점을 scss에서 보완하기 5.2.1 해쉬화 -> unique-id를 이용한 방법 (ment: 나머지 보완 형식은 뒤에 나올 8.설계 방식에서 개선)

  6. 스토리북 5.1 스토리북이란? 5.2 운영중인 프로젝트에 스토리북을 도입시 5.3 css in js 와 scss사이에서의 스토리북 5.3.1 css in js의 해쉬처리의 단점 해결 5.3.2

  7. scss와 styled를 같이 써본다면? (혼합 사용) 프론트에서 신경을 안써도 되는 ui부분은 scss로 작성(단순한 버튼의 상태에 대한 디자인, toggle형태에 대한 디자인, input의 상태에 따른 디자인) / 데이터와 theme가 필요한 부분은 styled로 작성. (ment: 예제를 보겠습니다.) 6.1 header - header 컴포넌트는 styled? scss? => styled. 6.2 button - button 컴포넌트는 styled? scss? => scss 6.3 같은 is- 라도 의미하는것은 다르다. (ment: is-active, is-fixed코드를 보여주며 어떤 차이점이 있는지 설명하기)

scss와 styled를 같이 사용하게 되면 나오는 이점은 프론트는 불필요한 ui는 신경쓰지 않아도 되고, 정의된 컴포넌트를 불러올시 맞는 테마를 선택하거나 맞는 props를 넘겨주기만 하면 된다는 점이다.

  1. 설계 방식 7.1 styled 7.1.1 styled의 변수 선언(theme) 7.1.2 장점 - 정의된 설계서 대로 만들면 된다. 7.1.3 단점 - 의존성이 커진다. 서로간에 깊은 관계로 맺어져있다.(ment: 추가 및 유지보수할시 정의된 변수를 추적,추적해서 갈 경우가가 많다.) - 보완: 너무 깊은 관계는 지양한다. 다양한 대처가 필요하지 않은 경우는 scss로 넘긴다. 7.2 scss 어떤 방식이든 scss를 사용할시에는 root에 funcion이나, variables가 정의되어 있다. 7.2.1 컴포넌트 1:1방식 7.2.1.1 장점 - ui와 스타일이 매치되어 유지관리에 편하다. 7.2.1.2 단점 - 중복된 클래스명이 나올 수 있다. - 보완: 컴포넌트 모듈화를 구체적으로 진행하거나 class명에 prefix 등을 붙인다. 7.2.2 layout 방식 - src 바로 아래에 폴더 별로 구성 7.3 atomic design 7.3.1 atomic design 간단히 훑어보기 - 어떤 방법으로 하는게 좋을까

  2. next환경에서의 스타일링 설계 8.1 next에서의 scss 8.1.1 컴포넌트 1:1 방식 next가 아닌 환경에서는 scss를 바로 import 하면되지만, next에서는 xx.module.scss를 사용해야 한다. 이 module은 next가 아니어도 사용할 수 있지만, 사용할 경우 코드작성이 더 필요하며 해쉬처리가 되어 추적이 불편하다. 8.1.1.1 css module - xx.module.scss scss이나 해쉬처리에 8.1.2 layout 방식 전역으로 사용할 시에는 기존처럼 scss을 그대로 사용할 수 있다. scss를 사용시 결과적으로 프로젝트의 규모, 성격을 파악 후 1:1 방식을 사용할지, layout 방식을 사용할 지 고민이 필요하다. 8.2 next에서의 css in js next환경에서의 styled는 별다른 차이가 없다.

여기까지 styled, scss, 약간의 emotion 환경을 접해보면서 느낀점은 ui는 로직과 분리하는게 편하다. 이다. 여기서 말하는 분리는 약간의 ui적 상태만 있으면 되지만, 그 ui적인 상태를 styled에서 관리한다면, 앞서 나왔던 단점들이 계속 유지가 될것이다. data와 ui를 분리한다는것. 그것이 지금까지 경험했던 것의 주관적인 정답이라고 생각한다. )

  1. vac 패턴 쉽게 말해 ui와 기능 분리. 9.1 기본 사용 9.2 좀 더 복잡한 사용 장점 - ui와 기능이 분리되면서 기능은 재사용할수있고, ui는 별도의 확인 용으로 사용할 수 있다. 단점 - 파일이 많아지고, 로직이 더복잡해진다?

  2. 완성형 컴포넌트와 비완성형 컴포넌트 여러분들이 생각하는 완성형 컴포넌트란 무엇일까요? 이 질문에 대해서 몇가지 생각나는 것들이 있을겁니다. 완전한 독립적, 다양한 상태에 대한 대응을 하지만 필요한 만큼의 props, 정형화 되어 있는 theme ui. ex) 칸으로 나뉘어져있는 progess bar 를 살펴보면 수치를 줄수있는 속성들이 widht, height, background-color, border-color, item-bgcolor, border-width 등등이 있습니다. 이런 많은 속성들 중에서 고정되어있는 속성, 변할 수 있는 속성은 무엇이 있을까요?

반대로 비완성형 컴포넌트는 이 모든것에 반대합니다. 끊으려해도 끊기지 않는 종속적, 무수히 많은 props. 정형화 되어 있지 않은 theme ui

  1. 번외: css 라이브러리
  • 설계서, 설명서를 보고 조립하며, 제작하는 것과 같다.
  • mui (ment: 가장 많은 컴포넌트, 가장 복잡한 기능들. 그래서 커스텀도 복잡하다.)
  • antd (ment: 중국산. 컴포넌트 내부의 텍스트가 중국어로 기본 제공. ui 자체는 이쁨)
  • reactstrap(react-bootstrap) (ment: )
  • tailwind (ment: )

11.1 장점 - 정의된 규칙, 방식에 맞춰 제작하여, 규칙과 방식만 맞춘다면 생산성이 높다. - props로 이루어진 컴포넌트라 scss의 함수들보다는 러닝커브가 낮다. 11.2 단점 - 정의된 규칙, 방식 자체를 새로 배워야 하는(설명서를 봐야 하는) 러닝커브가 있다. - 직접 처음부터 만든 부품이 아니기 때문에 커스텀 하는데에 상당한 무리가 있다. - 라이브러리 내부의 사용되지 않는 코드들때문에 무겁다.

  1. scss의 사실과 오해 scss의 필요성을 느끼지 못한다. 깊게 쓸 경우 개발자의 러닝커브가 필요하다 등의 꺼려지는 몇몇의 이유들이 있습니다. 하지만 실제로는 그렇지 않습니다. 12.1 일단 필요성은 앞에서 서술했던 대로 순수 ui만을 위한 스타일링을 위하여 사용됩니다. 12.2 '개발자의 러닝커브가 필요하다'는 lib나 hook처럼 사용성에만 도움을 되는것뿐이지 함수에 대한 종속성은 없습니다.

하지만 퍼블들이 부트스트랩을 커스텀하기 불편하다는 이유로 싫어 하는 것처럼, css 라이브러리들을 이용하고 직접 컴포넌트들을 만들지 않는다면, 컴포넌트를 설계 하는 능력(props, 분할 - solid, ui관리 등)을 고민 할 수 없게된다.

react는 사람마다 주관적인 코드가 잘 나타나는 라이브러리다. 그에 따라 앞서 설명했던 것처럼 여러 스타일링 설계 방식이 있다. 내가 설명했던 것들이 react의 스타일링 설계 방식의 전부는 아니겠지만, 꼭 한번은 여러분도 설계에 대한 고민을 했으면 한다. 그리고 한명의 사람이라도 이 내용들이 실제 스타일링 설계에서 도움이 되길 바란다.