[SidePJ] Issue-Cracker 4부 - v0.1.0🍪 데굴데굴 굴러가는 이슈크래커

 📌 Component 공유와 상태관리

 

FrontState 와 BackEnd State를 어떻게 관리해야 할까?

 

처음에는 담당자와 레이블마일스톤 을 어떻게 관리해야 할까 고민했다.

1) 눌러서 추가할 때마다 서버에 전송

2) FrontState에서 관리하고 이슈 작성을 누를 때 전송

GitHub의 담당자 상태관리는?

GitHub에서는 어떻게 관리하는지 확인해보았느데 누르때마다 서버로 전송이 되는건가? 했지만 로치의 말로는 아폴로 서버같이 동작하는것이지 실제로 그럴리가 없을 것이라 했다. ㅎㅎ

 

결과적으로 2번을 선택

이슈 생성하기 전까지 저 세가지 정보는 필요 없기 때문에 FrontState로 관리하다 이슈 작성 시 전송한는것이 경제적이라 생각했다.

 

 

 

처음 SideBar를 만들 때 IssueAdd 에서 동작하게만 만들다 보니 상태값을 다 가지고 있께 되엇다.

IssueDetail에서도 사용하려면 상태값을 전부 빼서 props로 전달받아서 뿌리는 방법으로 바꾸자

 

 

IssueDetail 과 IssueAdd 에서 동일하게 SideBar를 공유하면서

 

 

 

---

📌 Issue 상세페이지 상태관리 대격동 

 

 

기존 코드

IssueList의 Cell을 클릭하면 Link To 로 클릭한 해당 data(state) 를 쭉~~~~ 내려주고 SideBar에서 변경하면 그 값을 CheckedData로 관리한느 방식 

Recoil을 사용하는데 왜 계속 상태를 내려줘야 하는지 의문이 들긴 했다.

 

IssueDetail

const IssueDetail = (): JSX.Element => {
  const { state } = useLocation<IssueDataProps>();
  const setCheckData = useSetRecoilState(dropCheckState);

  useEffect(() => {
    setCheckData({
      assignee: state.assignees,
      label: state.labels,
      milestone: [state.milestoneInfo],
    });
  }, [state]);

IssueList - IssueCell

const IssueCell = ({ issues }: { issues: IssueDataProps[] }): JSX.Element => {
  const decoded = decodedToken && useRecoilValue(decodedToken);
  const profileURL = decoded && decoded.profileImageUrl;

  const openIssue = getIssue(issues, 'OPEN');
  const closedIssue = getIssue(issues, 'CLOSED');

  return (
    <>
      {openIssue.map((issue) => {
        const {
          assignees,
          content,
          createdDateTime,
          issueId,
          labels,
          milestoneInfo,
          status,
          title,
          writer,
        } = issue;
        const elapsedTime = getElapsedTime(createdDateTime);
        return (
          <S.IssueCell key={uuidv4()}>
            <>
              <LeftBox>
                <CheckBoxes />
                <IssueCellContent>
                  <Link
                    to={{
                      pathname: `/main/issue-detail/${issueId}`,
                      state: issue,
                    }}
                  >

 

SideBar의 Dropdown 메뉴 클릭 시 상태 관리

Recoil

export const dropCheckState = atom<dropCheckStateProps>({
  key: 'dropCheckState',
  default: {
    assignee: [],
    label: [],
    milestone: [],
  },
});

SideBar에서 체크한 정보들은 바로 Recoil로 넣어서 관리했다.

 const handleClickAssignee = () => {

      setDropCheck({
        ...dropCheck,
        assignee: [...dropCheck.assignee, data],
      });

클릭 시 상태가 변경되어 보이게 만들었다.

 

 

 

 

---

 

📌 활기찬 월요일의 코드 컨벤션 

1) useRecoilValue 네이밍 규칙 설정 

기존 방식

//SideBar
export const issueForm = selector({
  key: 'issueForm',
  get: async () => {
    const response = await fetch(U.FORM);
    const data = await response.json();
    return data;
  },
});

export const dropAssigneeState = atom({
  key: 'dropAssigneeState',
  default: false,
});

기존에는 useRecoilValue의 state와 불러와서 사용하는 변수간의 규칙이 없었다.  

코드를 구현할 때마다 그때그때 다르게 사용했었느데, 파일이 많아지고 복잡해지니 그 안에 규칙이 없어서 혼란스러웠고 네이밍고민이 길어졌다..

 

 

컨벤션 변경

useRecoilValue로 관리하는 곳은 상태이니 state를 붙이고 

가져와 사용하는 곳에선 이름 그대로에서 state를 빼기! 

간단한 규칙이지만 변경하는데 시간이 많이 소요되었고, 대신에 해당 패턴을 만낫을때 고민하거나 헷갈리는부분이 사라져 보다 직관적이게 코드를 이해하게 된 장점이 생겼다.

 

2) import 컨벤션 설정

import를 많이하고 깊이가 깊어질 수록 규칙이 필요하다고 판단해, 아래와 같이 import 순서를 정했다.

 

기본라이브러리

라이브러리

component

상태

스타일관리

이로 인한 장점은 파일을 딱 열었을 때 직관적으로 사용하는 파일들을 볼 수 있다는 점

다만 절대경로를 아직 설정하지 않아서 ../ ../ 이 남발하는데 추가할 예정이다.

 

📌BE와  공부한 REST API 와 선정 이유들

어떤 data들은 id가 number 이고 (단순 idx느낌) 

어떤 data들은 id 가 string 이다. 

number로 다 맞추면 되는데 왜 굳이 string이 되는 변수들에겐 그렇게 설정하였을까?

 

그 이유는 id 가 식별자 자체의 정보를 가지는 것이 중요하기 때문!! 

comment data 

실제 comment(댓글) data를 보면 

댓글의 id = 1 number

writer의 id = string인걸 볼 수 있느데, 

 

이는 댓글은 자체만의 고유한 정보가 없기 때문에 idx같은 숫자를 한 것이고 

writer은 이름이라는 자신의 고유한 속성을 가지고 있기 때문에 string을 한 것! 

 

 

data의  구조를 설계할 때 정말 많은 고민을 해야 한다는 것을 느꼈다.

 

 

 

POST와 PUT의 차이점은?

POST	X	생성	Issue 추가	요청할 때마다 새로운 data가 쌓인다
PUT	O	수정	Issue 수정	요청할 때마다 이전의 data를 없애고 그 자리를 대신한다
DELETE	O	-	-

PUT의 장점

• 렌더링으로 인해 여러번 호출해도 같은 결과를 보장한다.
• 부분적인 비동기 API 요청이 전해진다.
  

  

POST의 주의점

• 안전하지 않기 때문에 disabled 같은 UI 요소가 필요하다.
• 무한대로 렌더링 되고 API요청이 여러번 될 수 있다.

POSTMAN 공유 및 사용법

BE의 API를 확인하고 사용할 때 POSTMAN을 사용하면 실시간으로 자세하게 요청을 해볼 수 있는데, 여태껏 링크로만 공유하다가 그룹이 되어서 사용했다. 정말 편리해서 앞으로 마주할 때마다 사용할 방법을 간단하게 정리! 

1) import - Link

2) New - Environment 

 

정리 링크 : https://github.com/ghojeong/issue-tracker/wiki/%EC%A0%95%EA%B8%B0%EB%AF%B8%ED%8C%85-%ED%9A%8C%EC%9D%98%EB%A1%9D

---

📌 TypeScrit 에서 객체(json타입)  전달 시type 지정

같은 상황 해결 과정 :https://rrecoder.tistory.com/155

❖ 원하는 동작 

LabelTabel에서 labelList  배열을 map 돌며 LabelCell 컴포넌트를여러개 렌더링 하는 작업

여기서 label을 넘겨줄 때 label의 타입들을 지정해야 한다.

 

❖  이전 코드 

 

label 은 다음과 같이 생겼고 

label = {
  backgroundColor: "#1E4174"
  description: "라벨2 설명"
  id: 2
  textColor: "#FFFFF"
  title: "라벨2 제목"
 }

LabelProps

export interface LabelProps {
  id: number;
  title: string;
  description: string;
  backgroundColor: string;
  textColor: string;
}

LabelProps는 이렇게 따로 지정해 줬기 때문에 

 

const LabelCell = ({ label }: LabelProps): JSX.Element => {
  return (

LabelTable

const LabelTable = (): JSX.Element => {
  const labelList = useRecoilValue(labelListState);
  const labelListArr = labelList?.labels;

  return (
    <IssueTableContainer>
      <LabelTableHeader />
      {labelListArr?.map((label: LabelProps) => (
        <LabelCell key={uuidv4()} {...{ label }} />
      ))}
    </IssueTableContainer>
  );
};

 

 

❖ 수정 코드

그렇다면 json을 객체를 속성으로 넘길 때 타입지정하는 두가지 방법

 

1) 속성 자체를 props 이름으로 넘긴다

interface LabelPropss {
  label: {
    id: number;
    title: string;
    description: string;
    backgroundColor: string;
    textColor: string;
  };
}

const LabelCell = ({ label }: LabelPropss): JSX.Element => {
  return ( //중략

LabelPropss 를 보면 LabelCell에 넘길 props명을 미리 type지정을 해주면 생각했던 대로 넘길 수 있다.

 

 

2) type 선언 시 props명 할당해주기

export interface LabelProps {
  id: number;
  title: string;
  description: string;
  backgroundColor: string;
  textColor: string;
}

const LabelCell = ({ label }: { label: LabelProps })
//중략

type 선언 시에 LableProps 가 label이라는 것을 지정하면서 타입 지정을 할 수 있다. 

 

---

📌 버튼 외 영역 클릭 시 닫히는 로직 구현

1) ref 걸 component가 영구적이지 않은 문제 

ButtonBox

기존 코드

일단 ref를 거는 부분이 삼항연산자로 처리해놓았더니

 가독성도 떨어지고 조건에 따라 ref가 없을 수 도 있어서 변경이 필요했다.

<ButtonBox ref={editRef}>
          {issueEditTitle ? (
            <TitleEditButton
              startIcon={<TitleEditIcon />}
              color="primary"
              onClick={handleClickCompleteButton}
            >
              <TextGroup
                type={T.SMALL}
                content={TT.EDIT_COMPLETE}
                color="#007AFF"
              />
            </TitleEditButton>
          ) : (
            <TitleEditButton
              startIcon={<TitleEditIcon />}
              color="primary"
              onClick={handleClickEditButton}
              id={'editButton'}
            >
              <TextGroup
                type={T.SMALL}
                content={TT.EDIT_TITLE}
                color="#007AFF"
              />
            </TitleEditButton>
          )}

 

변경 코드

ButtonBox에 들어가야 할 Component를 분리한 후에

Component 내부에서 삼항연산자에 의해 나뉘도록 했다.

이렇게 바꿈으로써 어떤 조건이 있어도 ButtonBox는 고정되어 렌더링 되니 useRef 가 가능해진다.

 <ButtonBox ref={editRef}>
          <IssueDetailHeaderButtonSection
            state={issueEditTitle}
            id={issueDetails?.issueId}
          />
          <IssueDetailIssueCloseButton callback={setIssueState} />
        </ButtonBox>

const IssueDetailHeaderButtonSection = ({
  state,
  id,
}: {
  state: boolean;
  id: number;
}): JSX.Element => {
  return (
    <>
      {state ? (
        <IssueDetailTitleEditCompleteButton {...{ id }} />
      ) : (
        <IssueDetailTitleEditButton />
      )}
    </>
  );
};

 

 

2) 버튼 영역 외 클릭시

event의 타입 문제

버튼 외 영역을 눌렀을 시 편집 창이 종료되어야 한다.

현재는 편집버튼을 눌러야함 편집이 종료된다.

 useEffect(() => {
    const handleClickBody = (e: { target: HTMLInputElement }) => {
      if (editRef.current && !editRef.current.contains(e.target)) {
        setIssueEditTitle((prev) => !prev);
      }
      console.log(e.target);
      console.log('current', editRef.current);
      // setIssueEditTitle((prev) => !prev);
    };
    window.addEventListener('mousedown', handleClickBody);

    return () => window.removeEventListener('mousedown', handleClickBody);
  }, [editRef]);

---

📌 SideBar 의 상태 클릭 시 서버에 PUT요청 보내기

사이드바에서 담당자를 바꾸고 사이드바Drop을 닫을때 서버에 PUT요청을 보내며 수정하는 로직

일단 첫번째 고민했던 것은 서버에 요청을 보내는 타이

 

 

1) SideBarDrop에서 누를 때마다 PUT 할 것인지

2) 모달을 닫았을 때 보낼것인지 인데 

서버에 체크할때마다 보내면 모달을 닫을 때 보내는 것보다 훨씬 많은 서버 요청이 발생할 것이라고 예상해,

라쿤과 모달이 닫힐 때 요청하는 방향으로 결정했다!

 

담당자 편집 요청 코드

const dropCloseHandler = (e: MouseEvent): void => {
      if (dropAssigneeElement.current?.contains(e.target as Node)) return;
      if (dropLabelElement.current?.contains(e.target as Node)) return;
      if (dropMilestoneElement.current?.contains(e.target as Node)) return;

      setIsDropAssignee((prev: boolean) => {
        const assigneeUrl =
          U.ISSUES + '/' + issueDetailId.issueId + '/assignees';
        if (prev)
          getPut(assigneeUrl, userToken, {
            assigneeIds: getValueInJson(checkedAssignee, 'id'),
          });
        return false;
      });

      setIsDropLabel(false);
      setIsDropMilestone(false);
    };

SideBar 외 영역을 눌렀을 때에는 return 

Assignee SideBar DropDown외 영역을 클릭해 닫히는 상태로 변경 하는 로직 (setIsDropAssignee) 에서 

PUT 요청을 보내고 있다.

PUT요청 body 가 체크된 담당자들의 id만 배열로 전송하는 형식이기 때문에 ex) ['ink-0', 'Raccoon']

getValueInJson로 id만 불러오는 함수를 써서 body로 넣어준다.

 

맞이한 어려움

현재 이 함수는 useEffect 내에 들어있는데,

그 dependencyArray에 []빈배열 넣음 -> 처음 한번만 동작 -> 체크한 담당자(checkedAssignee가 초기값) 0으로 요청 

이 로직이 실행되서 자꾸만 요청을 하면 담당자가 사라지는 어려움을 겪었지만, 

 

dependencyArray에 chekedData( 체크한 담당자 외 레이블과 마일스톤도 포함)을 넣어줌으로써 

사용자가 체크한 데이터들이 바뀔때마다 다시 실행되도록 하여 데이터 수정 요청에 성공했다.

 

---

📌 현재까지의 상황

깃허브 로그인을 한 후에 만들고 싶은 이슈들을 생성, 편집하고 

레이블 마일스톤도만들어서 달 수 있다.

 

 

 

로그인  , 이슈리스트 (메인 화면)

 

이슈 생성 수정 삭제

 

레이블 생성 수정 삭제

 

 

마일스톤 생성 수정 삭제

 

 

 

 

시연 gif

로그인과 이슈 생성

 

마일스톤 생성, 레이블 생성

 

 

📌 짧은 회고

 

처음 만들 때 상태관리때문에 어지럽고 힘들었는데 

정말 잘 동작하는 걸 보니 너무 신기하고 재밌어서 계속 클릭하고 만지고 있다. 

지금은 버전1이고 아직 해결해야하는게 산더미지만, 일단은 제한된 범위 내에서 동작이 가능하다!!!! 너무 행복해..

 

물론 여기서 멈출 생각은 없고, 남은 Task들을 진행할 예정!