멘토님과의 시간 4주차
계획을 누가 주도하는 사람이 없다면 일하는데에 바빠서 계획을 못지키는 경우가 많은거 같음 해야할게 생기면 백로그에다가 집어넣거나 데일리 미팅에서 공유하기
데일리 스크럼에서 목표를 다시 다잡는게 좋은 거 같음.
이런 프로세스를 잘 해보는게 나중에 큰 도움이 될 거 같음.
null 체크하는 함수를 만들어 사용하려고 했는데 타입 에러가 떠서 활용하지 못함.
어떻게 해야할 지 ..
모두 다 거쳐가는 관문인 거 같음.
!를 통해 검사하는건 가급적 안하는게 좋은 거 같음
null 만 체크하는 게 아니기 떄문에 언젠간 문제가 생길 것 .
null 뿐만 아니라 undefined도 체크해야하는데 안했기 떄문에 에러가 뜰 수 있음 함수로 따로 뺏기 떄문에 parsing 할 때 따라가지 못하기 떄문에 해당 함수에서 어떤 걸 수행했는지 모르므로 발생 .. (최신 타입스크립트에서는 가능)
보통은 equal을 2개 사용하여 (==) 해결
null or undefined 는 == 로 체크하여 동시에 체크함 .
=> == 을 사용해서 체크하면 좋음
따로 함수를 만드는 거 보다 ==를 사용하는게 코드가 깔끔해짐 .
만약 if 조건이 길어진다면 함수로 따로 뺴는게 좋음 ! 단, 명확하게 함수 이름을 정해야 가독성이 좋아짐 + 코드가 좋아짐.
함수를 parsing하지 못할 때 parsing 가능하도록 하는 방법 -> throw /catch를 사용하는 경우 => heavy 해짐 -> 다른 방법도 있지만 코드가 오히려 더 복잡해짐 -> 널 체크 정도면 그냥 하는게 좋음 .
드롭다운의 위치는 변동, 모달은 고정되어 있습니다. 각 페이지에서 모달을 띄어주는게 좋을지, APP.tsx에서 모달을 전체적으로 관리해주는게 좋은지 궁금합니다.
리액트에서 ref 같은 건 서로 독립적인 게 좋습니다. 지금 상태는 app에 종속되어 있기 떄문에 어디서는 모달을 띄어줄 수 있다는 점에서 좋지만 재사용 측면에서 좋음.
모달을 독립적인 컴포넌트로 구성하고 props만 던져주면 모달이 생겨나도록 만드는 게 제일 좋음.
모달창을 컨테이너로 만들고 안에 들어가는 것들을 composition을 이용해서 넣어주는게 좋음
일반적으로 모달은 2가지 경우가 있는데 배경을 클릭하면 꺼지는 경우가 제일 간단함.
특정 모달 자체는 자기가 모든 처리가 가능하도록 만드는 게 좋음.
만약 외부를 클릭하면 모달이 사라지고 ... 다른 걸 클릭하면 띄어지고 ..
즉 모달 컴포넌트 스스로 자신의 기능을 다 할 수 있어야함 . 독립적으로 .
전역상태로 처리해서 만드는 거 보다 독립적으로 모달을 만들어주는게 좋지만 어려울 것
멘토님은 전역상태를 별로 좋아하지 않음.
편하긴 하지만 컴포넌트를 재사용하기 힘들어짐.
Props 가 많아 지는 게 두렵다면 Interface를 활용해서 InterFace의 Instance로 던져주는게 좋음.
외부 링크
외부 링크로 보내버릴 때는 새 창을 띄워줘야하기 때문에 a 태그를 사용하는 게 좋음 만약 Link를 사용한다면 새창을 띄워주지 않을 때 사용하는 게 좋음
Join 할 때 시퀄라이즈에서 데이터를 뽑아 낼 때 필터링 하는 과정에서 문제가 발생했습니다.
-
- as 를 사용해서 처리해주는 경우
-
- 가공해야할 데이터가 너무 복잡해서 새로운 객체를 생성해서 처리하였는데 엄청난 타입 에러가 떳습니다.
팀 객체에 유저 객체를 추가해야하는데, Team And Users 로 별도의 타입을 만들 수 있음. => Team.findAll로 나오는 타입을 해당 타입으로 리턴되게 해서 처리해주면 됨.
타입 스크립트에서 타입 에러가 많이 발생하므로 utility type을 많이 찾아보면 좋을 거 가틍ㅁ
Passport를 사용하는데 타입 에러가 계속 발생하여 외부 모듈의 타입을 재정의 할 필요가 있었음.
passport.d.ts를 작성하여 타입을 따로 정의해서 재정의를 진행 .
req.user.uid 를 접근해야할 때 Passport의 User 인터페이스에 uid가 없어서 문제가 발생했음.
User 인터페이스를 작성한 후 캐스팅 하는게 좋은 거 같음.
예를 들면 (req.user as myUser)로 해서 처리해주는 게 좋은 거 같음.
PassPORT에 있는 User는 인터페이스 이기 때문에 User를 상속받은 하위 인터페이스를 만드는 게 좋음.
클린 코드에 있는 명언 ..
코드를 받고 실행할 때 비교적 하나의 스크립트로 되도록 하는 게 좋음 -> 몇 개의 단계를 거치도록 하면 안좋음 -> 도커를 이용해 이미지로 만드는 것도 좋음 -> 백엔드를 할 때 아주 좋음.
테스트할때 도커 이미지 -> 실행 하는게 아주 좋음.
보통 npm install -> npm run build 하면 바로 되도록 하는게 좋음.
.env 를 production mode , development mode 를 따로 설정하여 바로 되도록 하는게 좋음
Readme.md 에 실행해야할 스크립트를 적어둬야함.
미래의 나를 위해 문서 작업을 해두는게 좋음.
이런 것도 모두 실력 향상의 방법.
리액트 할 때 유닛 테스트를 해보는 것도 좋음
만약 포트폴리오에 테스트가 있다면 대박 ..
스토리 북 -> 내가 만든 컴포넌트의 Props를 직접 화면에 올려서 어떻게 컴포넌트가 렌더링 되는지 테스트 해볼 수 잇는 툴 -> 이런 걸로 테스트해보면 아주 좋음
만약 기업에서 실제로 사용하는 기술을 바탕으로 포트폴리오를 작성하면 아주 도움이 될 거 같음 -> 도커 , 테스트 (제스트 + 스토리북)
꼬리에 꼬리를 물며 공부하는 게 좋은 거 같음
멘토님은 새 언어를 공부하는 걸 좋아하는데 , 30개 정도를 익히심 ㄷㄷ ; ; 이제 새 언어는 일주일이면 ...
주니어 때는 많이 경험해보고 많이 공부해는 게 좋은 거 같아용
깃 전략