2022.10.31(월)

TIL 🧐

주절주절 😗

다른 컴포넌트의 prop에서 sx prop 타입만 가져오기

const flexCss = {
  justifyContent: "center",
  alignItems: "center",
  gap: "10px",
} as Pick<ComponentProps<typeof FlexBox>, "sx">;

Table 컴포넌트의 ellipsis와 flex의 딜레마..

현재 테이블 안의 cell에서 필요한 역할은 text가 지정된 width를 넘어가면 … 처리할 것과 글자와 함께 아이콘이나 이미지, 댓글 수 같은 숫자가 함께 children으로 들어갈 경우 옆으로 나란히 되고 10px 띄워져야하는 것이다.
그래서 flexbox와 Text 컴포넌트를 이용해서 하려했는데.. flexbox가 감싸고 안에 Text가 들어가면 children이 Text 안으로 들어오니 flex가 적용되지 않고(flex속성은 바로 하위 자식에게만 영향을 주므로), Text로 감싸고 안에 flexbox속성을 주니 ellipsis 속성이 적용되지 않는다….(ellipsis 속성도 바로 하위 자식에게만 적용되는데 하위 자식인 flexbox에 적용될 경우 오른쪽의 아이콘까지 같이 … 처리 되버린다..)

근데 Text 컴포넌트를 테이블 셀이 소유하자니(th는 모두 bold체여야하므로) Text와 관련된 prop까지 th, td 태그들이 prop으로 받아야한다.. 그래서 고민하다 좀 분해되더라도 table을 사용할 때 직접 Text 컴포넌트를 사용해 원하는 텍스트를 만들어 children으로 넣어주는 방향으로 바꿨다. 그래서 더더욱 그냥 분리해서 max-width도 정해진 컴포넌트를 받는 식으로 하려고 했다.. 그런데 또 생각해보니 모든 th, td에 Text 컴포넌트를 감싸서 주고 공통으로 들어갈 ellipsis 속성을 추가해주는게.. 번거로워 보이기도 하고.. 고민이다ㅠ

아쉬워요 🙁

테이블 뿌수고 싶다..

잘했어요 🙂

진짜 내일은 PR 보낼 수 있을 듯..

2022.11.02(화)

TIL 🧐

주절주절 😗

Table PR 성공

ellipsis 처리 부분 때문에 고민이 제일 많았다.

th, td는 항상 한 줄이며 지정된 넓이를 넘을 시 … 처리된다. (텍스트만)

해당 부분을 처리하기 위해 Text 컴포넌트를 td 안에 넣었었지만

  1. FlexBox 안에 Text를 넣을 경우
<td>
  <FlexBox sx=>
    <Text as="div" ellipsis>
      {children}
    </Text>
  </FlexBox>
</td>

이 경우, children으로 text와 icon이 들어오는 경우 가로로 배치되지 못합니다.
display: flex는 바로 하위 자식들만 배치하기 때문입니다.

  1. Text 안에 FlexBox를 넣을 경우
<td>
  <Text as="div" ellipsis>
    <FlexBox sx=>{children}</FlexBox>
  </Text>
</td>

이 경우, … 처리가 되지 않습니다.
때문에 외부에서 … 처리를 하고 싶은 cell의 경우, 또 폰트를 변경하고 싶은 cell의 경우에 Text를 이용하여 children으로 넣어주는 방식이 낫다고 판단했습니다.

결론은 Text를 외부에서 받는 걸로..
그런데 만들면서 드는 고민은 한 컴포넌트가 다른 컴포넌트를 소유하면 소유한 컴포넌트들을 변경하는 prop을 또 받게 되어 prop이 커지고 섞이게.. 된다.
그렇다고 항상 밖에서 children으로 컴포넌트를 넣어주면 또 분해되고.. 딜레마다ㅠㅠ

아쉬워요 🙁

왜 벌써 11월이지……….

잘했어요 🙂

테이블 PR도 보내고, storybook에 예시를 위해서 스터디 맴버 관리 리스트 페이지에 사용할 table도 간단히 만들었다.
해당 페이지 만들 때 가져다 쓰면 될거 같다ㅎㅎ

2022.11.03(목)

TIL 🧐

주절주절 😗

햄디 Form, TextField PR

오늘 별거 안했는데 시간이 잘 갔다.. 햄디 PR을 어디가 바꼈는지 보느라 지난 PR부터 다시 보느라 오래걸렸다.
예전에 validate 하는 input을 만든 적이 있는데 그때는 form 없이 만들다보니 submit 이벤트를 사용하지 않았는데 이번에 햄디는 Form이 자신 안에 있는 input의 상태를 가지고 있고, 하위 input들이 form이 가진 상태를 변경하는 로직을 useForm으로 분리했다.
이 부분이 되게 깔끔해서 인상 깊었다. 그런데 예전에 상태를 가지고 있어야 커스텀 훅이 아닌가 라는 생각이 들어 찾아봤더니 상태를 가지고 있는 훅이라고 정의를 찾았어서 피어세션 시간에 물어본 적이 있다. 그 때 파크도 상태를 가지고 있어야한다고 얘기했다.
상태를 가지고 있지 않으면 helper 함수랑 다를게 없지 않나 하는 생각이 들었다. 댓글로 남겨놨으니 의견을 들어봐야겠다.
전반적으로 코드가 깔끔하고, 햄디가 시간이 오래걸린게 참 많은걸 참고했구나 생각이 들었다. 나는 라이브러리를 참고 잟하지 않고, 스스로 만드는 타입인데 다른 라이브러리들을 좀 참고하는 습관도 들여야겠다.
맨바닥에서 만드는거보단 참고하면서 내 생각대로 만드는게 발전되는 방향이 될수도 있으니?

아쉬워요 🙁

상세 컴포넌트 구상만 했다ㅠ

잘했어요 🙂

햄디 PR을 2시간 넘게 본거 같다. 첨부해준 링크도 읽어보느라 하하