[220729] 오늘의 배움(TIL) - Tailwind CSS / EDIYA 클론 코딩 팀 프로젝트 회고

💛 nalsae·2022년 7월 29일
1

📚 오늘의 배움(TIL)

목록 보기
15/84
post-thumbnail

🔸 Tailwind CSS

  • TailwindCSS 설치 명령어 뒤에 @latest를 작성하는 이유는 무엇인가?

: @latest를 함께 작성하면 최신 버전으로 설치하겠다는 의미

  • TailwindCSS 사용 시 input.css 파일에 꼭 작성해야 하는 것은 무엇인가?

: TailwindCSS 공식 홈페이지를 살펴보면 나와 있는데, @tailwind base, @tailwind components, @tailwind utilities를 꼭 상단에 작성해주어야 TailwindCSS에서 제공하는 유틸리티 클래스를 사용할 수 있음

  • TailwindCSS의 JIT 모드는 무엇이고, 어떻게 사용하는가?

: JIT은 Just-In-Time의 줄임말로, 원하는 스타일이 클래스명으로 지정되어 있지 않은 경우에 직접 CSS 스타일 명을 생성할 수 있는 모드를 의미
: 원래는 JIT 모드 사용 여부를 따로 config 파일에 명시해주어야 했는데 3.0 버전 이후부터는 JIT 모드가 내장되어 따로 명시하지 않아도 됨
: 클래스의 값에 [ ]를 입력하면 사용할 수 있음

  • TailwindCSS에서 JIT 모드 없이 클래스를 직접 생성하려면 어떻게 해야 하는가?

: 설치 시 생성되는 tailwind.config.js 파일에 포함된 theme > extend 객체 하위에 따로 원하는 클래스명과 값을 지정해주어야 함

  • TailwindCSS에서는 스크린 리더에서만 읽어주는 속성을 어떻게 지정하는가?

: TailwindCSS가 제공하는 유틸리티 클래스 중 sr-only를 사용하여 쉽게 설정 가능

  • @apply는 무엇이고, 왜 사용하는가?

: 공통으로 사용되는 속성을 묶어서 변수처럼 할당하고 싶은 경우 input.css 파일에 원하는 이름과 함께 등록하여 사용할 수 있음

  • TailwindCSS에서 배경 이미지는 어떻게 적용할 수 있는가?

: 배경 이미지 역시 tailwind.config.js 파일 안에 있는 theme > extend 객체 하위에 url 함수로 경로를 지정해주어야 함


🔸 기타

  • VS Code 확장 프로그램 설치 시 유의해야 하는 점은 무엇인가?

: 설치했다고 항상 바로 사용할 수 있는 것은 아님, readme 파일을 읽어보고 추가로 설정해야 하는 부분이 있는지 확인할 것


🔸 EDIYA 클론 코딩 팀 프로젝트 회고

💡 GitHub 링크

: https://github.com/ConnecTo-FrontEnd/EDIYA-Clone-Avocado


🔹 개발 프로세스

(1) Sass 폴더 구조 리팩토링

(2) 메인 페이지 Sass 파일 리팩토링

: 변수화, mixin 추가 적용 등

(3) iframe 영상 출력 이슈 해결

(4) CSS 스타일링 정돈

(5) GitHub를 통해 간단한 배포


🔹 참여한 작업

: (1) ~ (5) 전 과정


🔹 느낀 점 및 개선 사항

💡 공통 값 지정의 필요성

: 스타일링 병합 중에 분명히 내 컴퓨터에서는 제대로 잘 보였는데, 다른 팀원의 컴퓨터에서 살짝 레이아웃이 안 맞는 이슈가 발생했다. 디버깅하면서 그 원인을 찾아 보았는데, 정말 어이없는 실수 때문이었다. 기본이 되는 font-size 값을 지정하지 않았는데, 각각의 브라우저에서 기본으로 제공하는 폰트 크기 설정이 달랐기 때문에 서로 다르게 보였던 것이다. 정말 당연한 말이지만, 프로젝트를 진행하면서 공통으로 보여질 속성을 항상 고려하고 검사해야겠다고 체감했다. 그리고 정말 예상치도 못한 부분에서 크로스 브라우징 이슈가 발생한다는 생각이 들었다. 리팩토링을 진행할 때 더 꼼꼼하고 세세하게 살펴보는 과정이 필요할 것 같다.

💡 모호한 Sass 폴더 구조

: 어제부터 팀원들과 함께 끊임없는 논의를 했던 부분이지만, 폴더 구조를 정의하는 건 참 어려운 일이라는 생각이 든다. 구글링을 하여 찾아본 보편적인 폴더 구조가 존재했지만, 우리가 수행했던 작업에 적용하기에는 모호한 부분이 있었다. 우리는 한 페이지를 섹션별로 구분하여 작업을 했는데, 대부분의 Sass 폴더 구조에서는 페이지별로 Sass 파일을 생성해서 ‘pages’ 폴더에 따로 구분했다. 사실 섹션별로 작업한 파일을 ‘components’로 구분하기도 모호하고, 그렇다고 ‘layout’으로 구분하기도 모호해서 결국은 ‘home’이라는 파일로 합치는 과정을 수행했다. 그런데 합치고 보니 또 ‘home’ 파일의 볼륨이 너무 커진 것 같아서 컴포넌트화시키는 작업을 제대로 수행하지 못한 것 같아 아쉬움이 남는다. 앞으로 프로젝트를 계속 진행하면서 진행하고 있는 프로젝트에 적합한 폴더 구조를 계속 생각해봐야 할 것 같다.

💡 Sass 파일을 하나로 내보내는 이유

: 폴더 구조에 대해 논의하면서 새로 알게 된 사실이다. 우리는 여러 개의 HTML 파일이 있는 경우, 각각의 HTML 파일에 적용할 수 있는 Sass 파일을 각각 컴파일하여 적용하는 것이 컴포넌트 개발 관점에서 더 바람직할 것이라고 생각했다. 그러나 보편적으로는 여러 폴더를 ‘main.css’라는 하나의 파일로 컴파일하여 적용시킨다. 왜 이렇게 할까 계속 찾아봤는데 원인을 찾았다. 그 원인은 바로 캐시 때문이었다. 캐시에 CSS 파일을 처음 불러와서 저장해놓으면, 그 이후부터는 한 번 불러온 파일을 읽어들이기 때문에 렌더링이 빨라지는 것이다. 하지만 CSS 파일 여러 개를 연결시키면 그만큼 읽어들여야 하는 파일이 많아지기 때문에 렌더링 관점에서 좋지 않다.

profile
𝙸'𝚖 𝚊 𝚍𝚎𝚟𝚎𝚕𝚘𝚙𝚎𝚛 𝚝𝚛𝚢𝚒𝚗𝚐 𝚝𝚘 𝚜𝚝𝚞𝚍𝚢 𝚊𝚕𝚠𝚊𝚢𝚜. 🤔

0개의 댓글