Portfolio

질문

깃허브.. rebase vs merge?? rebase를 다루는게 은근 까다롭다.. 추가적으로 merge를 주로 썼을때 발생하는 커밋 히스토리가 더러워지는 문제점은 팀 전체에 큰 불이익을 가져오는지..

PR을 merge할 때 어떻게 merge하냐 → merge

→ 중요하다면 중요한건데 그렇게 크게 중요하지 않음. rebase나 merge나 쓰는데 다름없어서 취향대로 하면

JSX.Element vs ReactNode vs ReactElement

JSX.Element보다는 ReactNode를 사용하라는 글을 봤는데 ReactNode는 다양한 원시타입과 null, undefined도 허용한다고 해서 범용적으로 타입들을 허용하는데 타입스크립트에서 엄격한게 더 좋은 것이라고 생각됨.

그럼에도 JSX.Element는 deprecated 되고, 최근 타입스크립트 5.1에서는 ReactNode의 단점이 아예 사라져서 권장된다고 함. 컴포넌트가 반환하는 값이 원시타입일 경우도 있는건가? 조건부렌더링에서 null같은 값들도 허용하게 해주려고 있는 거겠지?

https://www.totaltypescript.com/jsx-element-vs-react-reactnode

→ 정답없음

input 관리할 때 ref vs state // 비제어 컴포넌트 vs 제어 컴포넌트

[ asd ] // 비밀번호는 8글자 이상 입력해야 됩니다

ref : 재 렌더링을 막지만 DOM에 접근

state : 재 렌더링이 빈번하게 발생하지만 DOM에 접근 X(직접)

[ a ] [ d ] sumbit 하는 시점에만 값을 알면 된다. (ref) / 실시간으로 올바른지 아닌지를 보여주고 싶어 (state)

현재 프로젝트는 input으로 관리되는 데이터는 최대4개정도임

—> 고려해볼점

실시간 데이터 관리를 할지 말지
input이 많은지(최소 3~40개 이상)
구현할때 뭐가 더 빠른지

환경변수 관리를 서버리스 함수로 구현?

현재는 .env 에 담고, gitignore로 API의 BASE_URL등을 가림(network탭등에 api호출할때 주소찍힘) → 훨씬 좋음 근데 BASE_URL 은닉은 불가능함(완전한 은닉은 proxy서버로! 이렇게하면 로컬호스트(절대주소)로 보내는 식으로 보여짐 그래서 가려짐)

자동화에서 깃헙 워크플로우에서 환경변수를 사용해야 한다면 vercel의 serverless를 사용한다면 vercel에 환경변수를 주입해놓음

폴더명 대소문자?(현재 컴포넌트명,페이지명을 담은 폴더만 대문자, 나머지는 소문자), 스타일드컴포넌트 파일명확장자 tsx vs ts

→ 정답없음, 중요하지도 않음. 알아서 하면 됨. 근데 스타일드 컴포넌트는 ts확장자가 맞음.(tsx 문법이 들어가지 않으니)

객체 타입만을 허용하는 타입가드


const typeCheck =Object.prototype.toString

if(typeCheck.call(data) !== "[object Object]"){
	return 에러

엄밀한 타입가드를 위해 자주 사용됨. 근데 타입스크립트 상에서 타입을 잘 걸러주는지도 확인해봐야함 → 안됨

JWT 토큰 vs Cookie

프로젝트

prettier가 eslint룰을 덮어쓰도록 마지막에 쓰기(현재 tan stack query관련 eslint룰이 적용되고 있지 않음)

페어프로그래밍을 자주 navigator와 driver바꿔가면서 진행해보기

폴더구조를 scope로 생각하고 관리하기(응집도를 생각하기)


--src/
			Home/
						Home.tsx
						apis/
						component/
						types/
						stores/

해당 폴더 안에서만 쓰는 파일들은 그 안에 따로 두어 폴더와 폴더 사이의 물리적 거리를 가깝게 하는 것이 최근 개발 동향=⇒유지보수 편함

보통 2번 이상 재사용되는 경우는 최상위의 common으로 빼는것도 좋음(중간 단계로 빼도됨, 선택사항)

근데 너무 시간 오래 쓰지 않기! 생각보다 그렇게 중요하지는 않음

폴더구조도 eslint룰로 설정 가능함

폴더명을 package.json에 나와있는대로 짓는것도 좋음. 근데 안 중요함

API 함수는 하나로 만드는것이 더 좋아보임. 사용할때 get.post등을 명시하고, path를 명시하고, body를 그때그때 적어주면 됨, 에러처리도 어차피 따로해야 함.

JWT토큰 api 요청 함수를 나누는건 불필요함. 어차피 브라우저에서 보내는 쿠키도 엄청 많은데 딱히 성능에 문제가 되지 않음.

api 에러처리는 사용하는 곳에서 많이 한다. 특히 가까울수록 좋음(발생하는곳과 처리하는곳이)

TanStack query

Floagting mode를 통해 상태관리 어떻게 하는지 볼 수 있음.

queryKey를 기준으로 상태관리, 단순히 데이터를 return하면 store가 불필요, 가공화된 데이터를 저장하고 return하는 기능이 필요하다면 store를 이용하는 것도 좋음

정규화에 대한 비용을 생각해 봐야함

7. 커피챗 01.01 22:00

질문

프로젝트