들어가기에 앞서 정말 마음에 와닿는 이야기를 들었어요.
책 <함께 자라기> 중에서...
이번에 잘하냐 못 하냐
하는 것은 그렇게 중요하지 않아요. 앞으로 기회가 수백, 수천 번 더 있다면 말이죠!
충돌하는 것이 정상이고 그것이 야생학습이예요.
지금 잘햐나가 아니라 지금 자라냐(성장)
는 것입니다.
누군가 옆에서 무엇을 해야할지 알려준다면 편하겠죠.
하지만 그런 상황이 평생 가능할까요?
지금 어떤 것이 나에게 필요한지를 판단해 나갈 수 있는 능력도 학습의 일부입니다.
우리 모두 조급해 하지 말고 나만의 길을 걸어가 봅시다.
<button type="submit"> 제출하기 </button>
기본 type은 submit입니다. 하지만 명시적으로 달아주면 좋겠어요!
HTML에서도 주석을 제거합시다..!
색상을 상수처럼 생각을해봅시다.
한 번 사용해도 디자인 시스템이 있듯이 모든 컬러를 다 관리하고 있다는 의미를 부여할 수 있기에 웬만하면 변수 처리
하면 좋을 것 같아요.
어떠한 케이스들이라도 방어합시다.
- 요청을 정상적으로 보냈고, 응답도 바라는대로
- 요청을 정상적으로 보낼 수 없거나 기대하는 응답을 받을 수 없다.
- 네트워크 연결 끊겼을 때 (오프라인)
- 개발자 모드 네트워크 탭에서 Offline으로 변경해볼 수 있어요.
- 네트워크/서버가 느려서 지나치게 오래 로딩되는 경우(timeout)
- 개발자 모드 네트워크 탭에서 SuperSlow로 변경해볼 수 있어요.
- API 서버 에러
- API 키 할당 에러
- 정상 응답이 왔지만
- 응답 결과가 없을 때
- 응답 값에서 UI에 필요한 일부 데이터가 빈 값이거나 필드 자체가 없을 때
API 요청에서는 정말 다양한 경우들이 존재할 수 있겠죠? 이를 생각해보는 시간을 가지는 것도 좋을 것 같아요.
2가지 방식이 있었죠? Intersection Observer를 사용하는건 어떨까요?
변경 사항의 예시가 어떤 것이 있을지 정도는 생각해봅시다.
경험을 통해 내가 하는 개발이 너무 앞서나간 것인지, 확장성을 고려한 디자인인지 파악해 봅시다.
node-fetch
/ jest > jsdomjest-fetch-mock
msw
mocking
할 수도 있고..class는 필수가 아닙니다!
15라인과 같은 규칙은 라인 수보다 역할 분리에 집중합시다!
HTML은 간단한 문서에서 시작한 언어예요.
CSS는 스타일을 주는 것이고,
동적인 기능은 JS를 한 스푼 더한 것이죠.