3주차 멘토님과의 시간

API 구조 검토

질문

질문 1) 컴포넌트 재사용에 대하여 Children vs props

향후 개발 확장성을 위해 다음 두 가지 방법 중 어떤 방법을 채택할지 고민입니다.
1. Children으로 전부 넣어서 확장성을 노리는 방법
2. 고정적인 값인 팀명/ 소개 / 가능시간 / 지역 인 태그들은 TeamInfoContainer에 children이 아닌 아래와 같이 고정적으로 사용하는 방법
3. 위의 두 방법을 절충하는 방법

1. children 사용 경우

// in InfoContainer
<div css={InfoContainerStyle}>
    <InfoImageContainer image={Image} />
    <InputContainer>{children} </InputContainer>
</div>

1-1 InfoContainer를 계속 재사용 해주는 경우

// in EveryComponent...

<InfoContainer>
    <InputLabel label="팀명" />
    <InputLabel label="소개" />
    <InputLabel label="가능시간" />
    <InputLabel label="지역" />
</InfoContainer>
 
<InfoContainer>
    <InputLabel label="팀명" />
    <InputLabel label="소개" />
    <InputLabel label="가능시간" />
    <InputLabel label="지역" />
    <InputLabel label="지역" />
    <InputLabel label="지역" />
    <InputLabel label="지역" />
</InfoContainer>

1-2 TeamInfoContainer와 UserInfoContainer를 만들어서 재사용하는 경우

// in EveryComponent...
<TeamInfoContainer />
<UserInfoContainer />

// in TeamInfoContainer

<InfoContainer>
    <InputLabel label="팀명" />
    <InputLabel label="소개" />
    <InputLabel label="가능시간" />
    <InputLabel label="지역" />
</InfoContainer>

// in UserInfoContainer

<InfoContainer>
    <InputLabel label="ID" />
    <InputLabel label="소개" />
    <InputLabel label="가능시간" />
    <InputLabel label="지역" />
</InfoContainer>

InfoContainer는 children을 받아와 재사용을 할 수 있는 구조입니다.
TeamInfoContainer를 생성하여 team 정보에 대하여 InputLabel을 고정적인 값을 넣어서 다른 컴포넌트에서 TeamInfoContainer를

2. props 사용 경우

// in TeamInfoContainer
const info = {
    team : ["팀명","소개","가능시간","지역"],
    user :  ["이름","소개","나이","지역"],
}

function InfoContainer({type}:{type:string}){
    

return (
    <div css={InfoContainerStyle} >
        <InfoImageContainer image={teamImage} />
        <InputContainer>
            {info[type].map((label)=><InfoLabel label={label}>)}
        </InputContainer>
    </div>)
}

3. 아니라면 아래와 같이 절충해서 구현해야할지 고민입니다!

// in TeamInfoContainer
const info = {
    team : ["팀명","소개","가능시간","지역"];
    user :  ["이름","소개","나이","지역"];
}

function InfoContainer({type,children}:{type:string; children:JSX.Element[]|JSX.Element}){
    

return (
    <div css={InfoContainerStyle} >
        <InfoImageContainer image={teamImage} />
        <InputContainer>
            {info[type].map((label)=><InfoLabel label={label}>)}
        {children}
        </InputContainer>
    </div>
)

멘토님 답변

Children vs Props

상황에 따라 각 방법이 ㅁ장단점이 있을 거 같음

Children 은 Composition 패턴에 해당되고 리액트에서는 Children 방법을 권장 Atomic 의 경우에는 모든걸 캡슐화 하기 떄문에 Props로 전달하는 방법 . 취향에 따라 선택하면 좋겠음. (가독성)

Template 단계까지는 안쪽에 데이터가 없는 형태 . Page에서 템플릿에 데이터를 넣어줌 .
그래서 데이터를 완전히 분리시켜주는게 좋을 수 있음

그냥 코딩 스타일, 취향에 따라 달라지기 떄문에 편한대로 하면 됨.
정답이 있는게 아님

멘토님의 경우 보통은 Children 이 필요한 경우에는 사용하고 그렇지 않은 경우엔 Props로 받아와서 함 외부에서 템플릿을 사용할 때 Props로 데이터만 던져줌 .
템플릿 안에서 계속해서 Props를 넘겨줌

Children의 경우 템플릿에서 직접 생성해서 넘겨주는 구조

백엔드 프로젝트 구조

질문 : MVC 구조라고 생각하고 Index(라우팀) - Controller (response) - Service(db 연동) 로 나뉨 -> 이 구조에 대해 어떻게 생각하시나요

답변 🔢 보통 이런식으로 함 .
2가지 방법이 존재하는데, index.ts에서 모든 라우팅을 처리하는 경우 (너무 커짐) 2번째 방법은 우리처럼 라우팅을 처리하는 경우 잘하셨음

보통 Controller에서는 비지니스 로직이 없는게 좋음
컨트롤러는 서비스에게 전달하고 다시 전달 받아 response를 보내주는게 일반적 .
authController에서 hash부분은 비지니스 로직이기 때문에 서비스에 있는게 좋을 거같음.
Controller에서 발생하는 endpoint의 경우 한곳에 모아서 처리하는게 좋을 수 있음.

handleJoin을 테스트 하려면 HTTP request를 보내야함 .
만약 소켓, graphQl에서도 같은 로직이 쓰인다면 복붙을 해야함.
따라서 다양한 요청에 대해서도 테스트, 사용이 되도록 만들어야함 .
코드 중복을 잘 생각해서 만들면 될 거 같음 . 디렉터리 구조는 좋은 거 같음.

Sequalize migration

현재 migration 안에 sync를 사용하고 있음 제일 처음에 db를 만들 떄는 상관없음.
force 때문에 테이블을 drop하고 다시 만듬 만약 데이터가 있는 경우에는 데이터가 다 날라가버림 보통 db 마이그레이션을 하는 목적은 db가 계속 바뀌는 과정에서 기존 데이터를 유지하면서 바꾸는 것임 .

언제든지 항상 같은 db schema를 만드는게 목적.
보통은 db migration 할 때 시퀄라이즈 에서는 UP 과 DOWN 이 있음 UP은 파일 순서대로 실행하고 DB에 migration 히스토리를 저장시킴.
다음에 실행할 때는 히스토리를 보면서 중복하지 않고 진행됨

UP을 지정해 두면 처음에 만든 TEAM 테이블이 히스토리에 저장되고 (칼럼을 추가한다든가 ) 다음에 마이그레이션을 하면 히스토리를 참조해 TEAM 테이블을 클론함.
DOWN 은 히스토리에 있는 애를 DROP(칼럼을 drop 한다던가) 하고 진행할 수 있음

따라서 UP 과 DOWN을 잘 사용하면(db 마이그레이션 툴) 히스토리를 계속 쌓아가면서 만들 수 있고 리팩토링 하면서 개발을 진행할 수 있음. + 데이터를 계속 유지할 수 있음 + 히스토리를 쌓아 갈 수 있음
=> 각 개발자의 Schema를 동기화해서 개발할 수 있음.