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