시리즈 소개
오프라인 PWA를 목표로 하는 To Do 웹앱 프로젝트 To Do Wild 를 개발하며 배운 것들을 적는 시리즈입니다.
- beta service (일단은 오프라인이 될겁니다.)
- github
웹폰트
AWS S3에 폰트 올려서 쓰기
보안을 먹여서, 특정 리퍼러에 의한 요청만 허용할 수 있다.
다음 순서대로 하면 된다.
할 때마다 헤매기 뭐같아서 적어둠.
1. 버킷 만들고 웹폰트 업로드
2. '권한' > '액세스 차단(버킷 설정)' 편집
- "임의의"로 시작하는 것들만 체크하고 저장
- 이제 새 ACL을 줄 수 있음
3. '권한' > '버킷 정책' 편집
{
"Version": "2012-10-17",
"Id": "http referer policy",
"Statement": [
{
"Sid": "어쩌구 저쩌구",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::버킷명/*",
"Condition": {
"StringLike": {
"aws:Referer": [
"https://허용할 도메인",
"https://허용할 도메인/*",
"http://localhost*",
"http://localhost:*",
"http://127.0.0.1*",
"http://127.0.0.1:*"
]
}
}
}
]
}4. '권한' > 'CORS(Cross-origin 리소스 공유)' 편집
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET"
],
"AllowedOrigins": [
"https://*.허용할 도메인",
"http://localhost:8118",
"http://localhost:8228",
"http://localhost:5173",
"http://127.0.0.1:5173"
],
"ExposeHeaders": []
}
]- 이제 다시 '권한' > '액세스 차단(버킷 설정)' 편집
- "새"로 시작하는 것들만 체크하고 저장
- 이로써 현재 저장돼 있는("임의의") ACL은 퍼블릭 접근이 차단되지 않음
도메인 추가할 때마다 2~5를 반복한다.
Overused Grotesk
개인적으로 "헬베티카 못잃어" 주의인데, 웹에서는 헬베티카나 SF Pro는 못쓴다.
아무래도 시중의 정답은 프리텐다드 아니면 Spoqa Han Sans지만...
정녕 그것뿐이냐며 저혼자 대안 찾아 떠난 삼만리 길...
이제는 Overused Grotesk에 정착해도 될거 같다.
그전까지는 FreeSans를 써왔다.
내가 원하는 건 이 정도의 우직함과 물성이 있는 그로테스크다. 내 취향상 Inter나 Roboto 등은 너무 미끈하고 무기질적인 것이 좀 기분 나쁘기까지 하다.
TailwindCSS
왜 TailwindCSS인가? — 실무 입장에서
내가 내린 결론부터 말하자면, 너무 많은 컴포넌트 조각들을 만들지 않기 위한 타협점이라고 생각된다.
꼴랑 투두앱 하나 만들어보고서 하는 소리치고는 좀 거창하지만...
예컨대 다음과 같은 문제가 있다.
어떤 단추가 있다.
기능상으로는 쓰임새가 다양한데, 스타일은 약간 복잡한 스타일이 전역적으로 적용되어야 한다.
이때 이 단추의 partial component를 만들어야만 하는가?
컴포넌트 기반 라이브러리 관점으로만 이 문제를 생각하면 꼼짝없이 <Danchoo> 컴포넌트를 만들게 된다.
그리고 이런 기능 저런 기능을 다 수용해 나가는 동안... 그 컴포넌트는 조건문이 가득한 괴물이 되어간다.
단추 주제에 말이지.
마지막 직장에서 FE팀이 관리하고 있던 클라이언트 소스가 정확히 그랬다. 기획서가 종이 1장을 미처 못 채우는, 그래서 디자인팀 피그마도 안 나올 정도로 간단한 변경인데도, 이런저런 이유가 있어서 수용에 시간이 걸린다는 것이었다. 백엔드 입장에서도 좀 딱해 보였다. 처음에는 그저 공통된 스타일링을 하나 적용하고 싶을 뿐이었을 텐데.
TailwindCSS는 이 부분의 타협점을 제시했다는 느낌이다.
- 컴포넌트 기반 클라이언트 개발을 전제로 한다.
TailwindCSS는, 어떤 스타일링이 반복될 경우, 이것이 어떤 차원의 반복인지 구분하라고 요구하고 있다. 컴포넌트 차원의 근본적 반복이라면 컴포넌트화를 해야 하고, 단순히 우연의 일치로재수없이발생한 스타일링 차원의 우발적 반복이라면 그냥 그렇게 써야 한다는 / 써도 된다는 관점이다. - 그런 의미에서 지나친 DRY를 배제한다.
일정 수준의 장황함과 반복은 TailwindCSS에서 허용된다. 정확히는 그 반대다.@apply같은 것을 써서 뭔가를 추상화 일원화할 수 있기는 하지만, TailwindCSS는 이를 권고하지 않는다.
원래는 이런 통찰(?)을 얻을 계획은 없었는데, 버튼에 Feather Icons를 써볼까 싶어서 이것저것 고려해본 것이 계기가 되었다.
- 쌩으로 아이콘을 받아서
<button>태그에 쓰기 - 남이 만든 컴포넌트 가져다 쓰기
최종적으로는 그냥 미관상 아이콘 없는 버전으로 만들긴 했지만.
cheatsheet
밑줄 같은 밑줄을 치려면 .underline-offset-4.
이거보다 작은 숫자를 쓰면 밑줄이 글자에 걸린다. (그런 걸 밑줄이라고 불러도 되는 걸까...?)
.sticky 클래스 쓸 때는 .top-n 또는 .bottom-n 클래스 잊지 말기.
둘 중 하나는 있어야 .sticky 클래스가 작동한다.
.sticky에 자주 쓰는 '위/아래로 사라지는' 투명 그라데이션은 대략 이런 느낌으로 깐다.
<!-- 아래로 사라짐 -->
<div class="pb-3 bg-gradient-to-b from-white from-90% to-transparent"></div>
<!-- 위로 사라짐 -->
<div class="pt-3 bg-gradient-to-t from-white from-90% to-transparent"></div>그라데이션이 투명으로 끝나기 때문에, 허전해 보이지 않기 위해서는, 사라지는 방향으로 패딩을 줘야 한다.
.last: 등의 유사클래스가 존재하므로, 문서 읽어보고 적극 활용할 것.
Vue
왜 <template>은 유일한 <div>로 감싸야 할까?
어쩌다 보니 실수로 이런 하위컴포넌트를 저장했는데, 렌더링은 잘 됐다.
<!-- 예컨대 Foo.vue 파일이라고 하겠음 -->
<template>
<div>...</div>
<div>...</div>
</template>뭐지? 나는 지금껏 <template> 밑에는 단 하나의 텅 빈 <div>만 있어야 한다고 배웠는데 내가 잘못 배운 건가?
문서를 확인해 보니 내가 잘 배운 게 맞는 것 같다.
위의 사례는, 문서에 따르면, "루트 노드가 여러 개인" 템플릿이다.
이런 템플릿은, 렌더링 자체는 되지만, 컴포넌트로 사용할 때 클래스/스타일 등이 전달(fall through)되지 않는다.
<!-- 여기에서 주는 class는 어디에도 적용되지 않고 전부 씹힌다. -->
<Foo class="text-xl text-bold" />그렇다면 루트 노드가 단일해야 한다는 것은 알겠고, 왜 그 노드는 아무 속성도 갖지 않는 텅 빈 엘리먼트여야 하는 것일까?
별거 없고, Vue는 클래스 속성을 전달하면서 병합을 하기 때문이다.
코드 예제는 문서 쪽을 참고하시길 바라며...
암튼 그런 이유로, <template> 밑에는 단 하나의 텅 빈 <div>를 주는 것이 좋은 관행이다.
요컨대 그것은 fall through되는 속성들(만)을 수용하는 wrapper로서 기능한다.
그리고 그런 wrapper로 쓰기에 제일 만만한 게 div 엘리먼트일 따름이다.
이런 걸 배우게 될 줄은 몰랐는데 아무튼 배운 건 배운 거니까...
