따라서 css를 쓰는 것은
괜찮은 옵션입니다
이전에 보았듯이 코드를 분리하고
조건부적으로 스타일을 적용하는 것은 꽤 간단합니다
그러나 우리가 가진 하나의 잠재적 단점은
css 코드와 css 규칙이 컴포넌트에 스코핑되어있지 않고
따라서 더 많은 컴포넌트에 영향을 끼치는
css 코드를 실수로 작성할 수 있다는 것입니다
그리고 우리가 이 애플리케이션에서 볼 수 있듯이
이 레이블을 살펴보면
원래는 정렬되지 않았던 것들이 이제 중앙으로 정렬되어 있습니다
하지만 이것들은 마치 여기 input 처럼
paragraph 안에 있기에 중앙으로 정렬된 것입니다
따라서 이 섹션에서 전에 바꿨던 header css 규칙으로 인해서
모든 단락에 대해 텍스트를
중앙으로 정렬하는 규칙이 적용되어
이 레이블이 중앙 정렬되어 있는 것 같습니다
이는 여기서 원하는 모양이 아닙니다
물론 여기서 고치려면 해당 헤더를
paragraph 앞으로 가져와야 하기에
이 헤더 내의 paragraph만 대상으로 합니다
그러나 이는 물론 개발자로서
규칙과 선택자에 대해 신중하게 생각해야 함을 의미하며
이는 좋을 수도 있지만
어느 정도의 추가 작업이 필요하다는 것을 의미합니다
대신, 이것은 스코핑되면 더 좋을 것입니다
다시 말해 이것이 가져온 파일에서 정의된 컴포넌트 이외의
다른 컴포넌트에
영향을 미치지 않길 원합니다
이것은 css 모듈을 사용하여 달성할 수 있는 동작이고
이를 통해 vanilla css 코드와 규칙을 작성하고
스코프로 지정할 수 있습니다
css 모듈은 최종적으로
리액트 프로젝트에서
사용되는 빌드 프로세스에 의해 구현되고
꼭 적용되어야 하는 접근 방식이며
이는 기본 브라우저나 자바스크립트 기능이 아닙니다
대신 css 모듈은 빌드 도구가
css 클래스 이름을 변환하고
파일당 고유한 것으로 보장되는
클래스 이름만을 사용하는 방식입니다
이를 설명하기 위해
여기 Header.css의 p요소 선택자 대신
. 을 앞에둔 paragraph 클래스
선택자로 전환해 보겠습니다
이제 물론 여기에 className paragraph를 추가할 수 있으며
결과적으로 이전과
같은 스타일을 얻게 됩니다
그러나 더 이상 이 레이블은 해당 클래스를 가지고 있지 않기에
해당 스타일을 얻지 못합니다
그러나 className paragraph와 함께
저의 레이블을 포함하고 있는 이 클래스를 여기에 추가하면 여전히
이것이 추가되면
여러분은 다시
중앙 정렬되는 것을 볼 수 있습니다
왜냐하면 css 클래스를 선택자로 사용하면
이러한 스타일이 스코프로 지정되지 않기 때문입니다
그러나 이것들은 다시 이 header css 파일을
header.module.css 로 다시 이름 붙이면 다시 스코핑될 것입니다
.module 이름 패턴은
기본 빌드 프로세스에 대한 신호로 볼 수 있습니다
따라서 여기 프로젝트에서
사용되는 vite 빌드 툴은 살짝 다르게 진행하기 위해 사용되는
이 파일을 약간 다르게 처리 하기에 이 vite 빌드툴은
파일을 가져오는 방법을 바꾸어야 하는 것 뿐 아니라
물론 이 이름을 변경해야 되는 이유 때문입니다
그리고 이제는
header.module 파일에서 무언가를 가져와야 하며
그 무언가는 빌드 과정에 의해
생성되는 자바스크립트 객체입니다
이 객체를 classes 또는 styles 같이
원하는 대로 네이밍 할 수 있지만
classes는 이 객체가
고유한 클래스 이름으로
변환된 클래스 이름을
포함할 것이기에 적절한 이름입니다
예를 들어 여기에서는 이 paragraph 클래스에 대한 것입니다
여기 추가된 import와 함께
우리는 이제 이 paragraph로 가서
className을 위한 텍스트 값으로 paragraph를 추가하는 것 대신에
동적 값을 추가해야 합니다
그리고 여기에 import하는 클래스 객체를
여기 .paragraph에 액세스하기 위해서 추가합니다
왜냐하면 여기에 paragraph라는 class가 있기 때문입니다
만약 이것이 .para라면
우리는 여기서 .para에 접근해야 하지만
paragraph를 이름으로 설정했기에 두 파일에서 모두 이것을 사용하겠습니다
이로써 저장한다면
전과 같은 결과를 보게 됩니다
그러나 이 paragraph를 검수하면
헤더에서 여러분은 흥미로운 것을 보게 됩니다
렌더링된 DOM에 적용된 클래스를
살펴보면
여기에 당연히 우리가 고르지 않은
이상한 이름이 있는 것을 볼 수 있습니다
paragraph를 포함하지만 또
더 많은 문자와 단어를 포함합니다
이 이상한 클래스 이름은
최종적으로 빌드 툴에 의해 자동으로 생성되었습니다
그리고 여기 헤드 섹션을 살펴보면
주입된 스타일에서
전에도 있던
모든 다른 요소 선택자들이 있습니다
그러나 여기 paragraph 클래스는 변형되었습니다
이것의 이름이 변형되었습니다
몇 초 전에 우리가 본
paragraph에 적용된 이상한 이름입니다
이것이 css 모듈의 개념입니다
이 클래스 이름은 이제 이 컴포넌트 파일 및
이 컴포넌트에 대해 고유합니다
다른 파일, 다른 컴포넌트에서 여기 텍스트로 paragraph를 추가하면
이 레이블이 영향을 받지 않는 것을 볼 수 있습니다
실제로 이 controls 및 이 paragraph를 검사하면 당연히
paragraph 클래스가 있지만 이것은
아무 효과가 없습니다
왜냐하면 원래 이 paragraph 클래스 이름은
header.module css 파일에서 정의한 것이
빌드 과정에 의해 변환되기 때문입니다
따라서 최종적으로는 이 빌드 과정은
제 클래스 스타일이 가져온
컴포넌트 파일로 스코핑되도록 보장합니다
이것이 거의 vanilla css를 활용하여
css 규칙 스코핑을 수행하는 방법입니다
그리고 물론 여러분이 원한다면
이것과 같이 클래스를 조건부적으로 적용할 수 있습니다
여기에 조건들이 있다면
당연히 이것은 의미없는 예시입니다
이것을 클래스 혹은 정의되지 않음을
이 조건이 부합하는지 아닌지에 따라 적용할 수 있습니다
따라서 전에 배운 것처럼
이것을 조건적으로 적용할 수 있고
여기 문법에 이것들과 함께 문자열로 주입할 수 있습니다
왜냐하면 당연히 결과적으로
이 paragraph 속성 아래 저장될 값은 문자열이기 때문입니다
빌드 툴에 의해 생성된
고유한 클래스 이름이 될 것입니다
그래서 모든 것은 작동합니다
여기서 다시 로딩하면
vanilla css처럼 작동하는 것을 볼 수 있습니다
그러나 여기 추가적인 스코핑이 추가되었습니다
따라서 css 모듈의 장점은 물론 여전히
css코드가 jsx 코드와 독립되어 있다는 점입니다
즉 css 코드를 알고 있는 것처럼 작성하고
그것을 좋아한다면
다른 사람이 작성할 수 있습니다
vanilla css에 대한 것과 마찬가지로
이제 css 클래스 및 이것을 사용하는 규칙이
해당 규칙을 가져온
css 파일을 포함하는
컴포넌트 파일로
스코프되는 추가적인 장점이 있습니다
당연히 단점도 있습니다
왜냐하면 여러분이 css를 아직 알아야 하고
우리는 결국 아직 vanilla css를 사용해야 하기 때문입니다
그리고 css 모듈을 사용할 때 새로운 단점은
여러분이 이를 사용할 때
프로젝트에
상대적으로 작고 많은 css파일을 마주하게 될 수도 있다는 것입니다
왜냐하면 여기서 이미 볼 수 있듯이
우리는 몇 css 코드를 포함하는
module.css 파일을 가졌고
또 AuthInputs을 추가할 수도 있습니다
많은 컴포넌트가
각각 자체의 css 파일을 가지는 큰 프로젝트가 있다면
적어도 일부 css 파일에는 그리 많은
css 코드가 들어 있지 않을 것으로 예상됩니다
이는 물론 단점으로 간주될 수 있습니다