알고리즘 공부를 하면서 자주 등장하는 개념인 순열과 조합에 대해서 정리해보기.

순열(Permutation)

개념

순열이란, 서로 다른 n개의 원소에서 r개를 중복없이 순서에 상관 있게 선택 또는 나열하는 것을 말한다. 즉 예를 들어 123과 213을 다르게 취급한다는 특징이 있다.

구현

const 순열구하기 = (array, r) => {
  const visit = Array.from({length: array.length}, () => 0);
  const temp = Array.from({length:r}, () => 0);
  const result = [];

  const DFS = (level) => {
      if(r === level){ // 레벨과 뽑을 수가 같아지면 결과값에 푸쉬(123, 132 등)
        result.push(temp.slice());
    } else{
        for(let i = 0; i<array.length; i++){
            if(visit[i] === 0){
                visit[i] = 1; // 체크를 하고
                temp[level] = array[i]; // 값을 넣어주고
                  DFS(level+1); // 다음 레벨로 넘기고
                   visit[i] = 0; // 끝났으니 체크를 초기화 해주기
            }
        }
    }

  }
  DFS(0)
  return result
}

조합(Combination)

개념

조합은 서로 다른 n개의 원소에서 r개를 선택하는 것은 순열과 비슷하지만 순서가 상관 없다는 점이 차이가 있다. 즉, 123과 213을 동일하게 취급한다.

구현

const 조합구하기 = (array, r) => {
  const temp = Array.from({length:r}, () => 0);
  const result = [];

  const DFS = (level, start) => {
      if(r === level){ // 레벨과 뽑을 수가 같아지면 결과값에 푸쉬(12,13 등)
        result.push(temp.slice());
    } else{
        for(let i = start; i <= array.length; i++){
          temp[level] = i; // 값을 넣어주고
          DFS(level+1, i+1); // 다음 레벨로 넘기고  
        }
    }

  }
  DFS(0,1)
  return result
}

웹 어플리케이션을 만들다 보면 수 많은 Form 들을 만나게 된다. 상황에 따라서는 단순히 2~3개의 입력이 아니라 여러 개의 입력을 받고 유효성 검증까지 함께 해야하기 때문에 매번 골머리를 않는 부분이기도 하다. 특히, 사용자의 입력마다 유효성을 검증하고 에러 메세지를 보여줘야 하는 경우에는 렌더링 최적화에 대한 고민이 들어가게 되고, 이를 이해 코드를 작성하다 보면 또 엄청 복잡한 코드를 마주하고는 인상을 쓰게 된다. 팀 간에 협업을 진행하면서도 Form을 어떻게 작성할 지 협의가 쉽지 않아지는 포인트이기도 하다. 이를 개선하기 위해서 도움을 받을 수 있는 라이브러리가 있는 지 찾아보게 되었고 나는 React-hook-form 은 어떤 라이브러리인지, 어떤 문제를 도와줄 수 있는지 살펴보려고 한다.

설치하기

# 지원하는 리액트 버전
npm i react-hook-form

# 지원하지 않는 리액트 버전
npm i react-hook-form --legacy-peer-deps

기존 Form 방식

const App = () => {
  const [values, setValues] = useState({
    email: "",
    password:"",
    passwordCheck:"",
    phone:"",
    agreement: "",
  })

  const onChange = (e:React.ChangeEvent<HTMLInputElement>) => {
    const {name, value} = e.target;

    setValues(prev => ({
      ...prev, [name] : value.trim()
    }))
  }


  return( 
    <Container>
    <Input name="email" value={values.email} onChange={onChange}/> 
        <Input name="password" value={values.password} onChange={onChange}/>
        <Input name="passwordCheck" value={values.passwordCheck} onChange={onChange}/>
        <Input name="phone" value={values.phone} onChange={onChange}/>
        <Input name="agreement" value={values.agreement} onChange={onChange} type="checkBox"/>
    </Container>
   )
}

기존에는 폼을 작성하기 위해서 신경 쓸 부분이 많았다. 각 input에 대한 상태값을 관리할 필요가 있었고 이를 위해 각 상태를 따로 작성하거나 하나의 useState에 객체로 관리하거나 해야했다. 여기에 각 입력마다 error 상태를 관리하기 위해서는 error에 관한 상태를 또 만들고 매 입력마다 이를 확인하는 로직을 추가해야 했다. React-hook-from을 사용하면 이를 훨씬 간단하게 작성할 수 있다.

React-hook-Form 적용하기

useForm

useForm을 이용하면 번거롭고 복잡한 코드를 간단하게 작성할 수 있다.

import React from "react";
import { useForm } from "react-hook-form";

export default function App() {
  const { register, handleSubmit } = useForm();
  const onSubmit = data => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("firstName")} />
      <select {...register("gender")}>
        <option value="female">female</option>
        <option value="male">male</option>
        <option value="other">other</option>
      </select>
      <input type="submit" />
    </form>
  );
}

우리가 연결하고자 하는 Input 에 register 을 이용해서 연결할 수 있는데, 이때 인자로 넣어주는 문자열은 name이라고 생각하면 된다.

handleSubmit의 경우에는 submit의 기본 이벤트가 발생할 때 리프레쉬 되는 현상을 막아주면서 콜백으로 전달된 함수에 input에 담긴 value 들을 담아 실행시켜주기 때문에 복잡하게 추가 로직을 작성할 필요 없이 사용할 수 있다.

컴포넌트에 적용하기

위의 register 방식을 통하면 손쉽게 form을 관리할 수 있지만 다른 라이브러리에서 제공하는 컴포넌트나 내부에서 작성한 컴포넌트의 경우에는 바로 register을 적용할 수 없다. 이를 대비해서 Controller 가 제공된다.

const {
    control,
    getValues,
    formState: {errors, isValid}

} = useForm({mode: "onChange", reValidateMode: "onChange"})


return  <InputWrapper>
          <Controller
            render={({ field }) => (
            <WithLabelInput
              type="text"
              label="이름"
              {...field}
            />
          )}
            control={control}
            name="이름"
            rules={{ required: true }}
            defaultValue=""
          />
          <SpaceY space="8px" />
          {errors?.이름 && (
            <WarnMessage
              message="이름을 입력해주세요."
              isError
              fontSize="14px"
            />
          )}
        </InputWrapper>

Controller에 각• 요소는 다음과 같다.

• render : 전달하고자 하는 컴포넌트를 전달할 수 있다. 에러메세지를 방지하기 위해서 직접 구현한 컴포넌트의 경우에는 ref를 전달받을 수 있는 형태로 작성하고, defaultValue를 통해서 밸류 관련 에러도 방지할 수 있다.
• rules : 유효성 검증을 위해 필요한 내용을 입력해 줄 수 있다. 상황에 따라서 required, pattern 등을 사용할 수 있다. 타입과 메세지를 입력하는 경우에는 유효성 검증을 통과하지 못한 경우에 보여줄 메세지도 입력할 수 있다.
• errors : 유효성 검증을 통과하지 못한 경우에는 에러 객체에 내용이 담기게 된다. type과 message의 형태이기 때문에 각 상황에 맞게 에러 메세지를 보여줄 수 있다.
• isValid : 유효성 검증이 마무리 되어 있는지 상태를 boolean으로 알려주는 값이다. 제출 버튼의 활성화 상태와 관련해서 사용할 때 유용할 수 있다.

적용 모습

간단하게 작성해 본 입력 modal의 모습이다. 각 input의 유효성을 실시간으로 검색하면서도 리렌더링을 유발시키지 않고 있다. 또한, 동일한 동작을 하는 기능임에도 불구하고 훨씬 적은 코드를 작성할 수 있었다.

개선이 예상 되는 점

기존

• 여러가지 입력의 상태를 관리하며 에러 메세지를 보여줘야 했기 때문에 많은 리 렌더링이 발생해야 했다. 입력이 적은 경우에는 문제가 없겠지만 많은 경우에는 불필요하게 많은 리렌더링이 성능에 나쁜 영향을 줄 수 있다고 생각했다.
• 렌더링을 줄이기 위해서는 memo 등을 이용해 각자 최적화를 해야 했고, 이를 위해서 입력을 관리하는 로직이 지나치게 복잡해지는 경향이 있었다. 특히 여러 개의 입력을 관리하는 경우에는 상태를 계속 전개 연산자를 통해 복사하면서 진행해야 해서 실수를 유발하기 쉬웠다.

변경

• React-hook-form의 경우에는 옵션에 따라서 리 렌더링을 발생시키지 않을 수 있기 때문에 불필요한 렌더링을 줄일 수 있었다.
• 상태를 직접적으로 관리할 필요 없이 React-hook-form 에서 제공하는 함수를 통해 가져올 수 있었으며, 에러 메세지 또한 에러 객체를 통해서 쉽게 적용할 수 있었다.

마무리

이렇게 React-hook-form에 대해서 간단하게 살펴 봤다. 당장 프로덕트에 적용한 것이 아니라 검토하는 과정에서 간단하게 작성을 해봤기 때문에 실제로 사용하면서 많은 문제들이 발생할 여지는 있다. 항상 일하면서 느끼는 부분이지만 개발이 들어가게 되는 경우에 생각보다 많은 변수들이 발생하고 이를 해결하기 위해서 라이브러리와 고생을 해본 경험은 많으니까. 그렇기 때문에 직접 작성하고 최적화만 잘하면 되지 않겠냐는 생각이 들 수도 있고, 한 적도 있다. 그럼에도, 라이브러리를 사용해서 얻을 수 있는 이점은 불필요한 코드의 양을 줄이고 협업하는 과정에서 의사 소통에 들어가는 시간의 낭비를 줄일 수 있는 부분이라고 생각한다. 적은 코드를 작성하면 버그도 줄어들테니까. 다음 React-hook-form과 관련된 글은 실제로 적용하면서 겪었던 문제들과 이를 해결하는 과정에 대해서 정리해보려고 한다.

회사 프로젝트에 React Query를 도입시켜보면서 그동안 함부로 건들지 못했던 API 핸들링 관련 로직을 건들어야만 했다. React Query 잘 도입해서 팀원들이 편하게 사용할 수 있으면 좋겠다는 마음이 들어 대대적으로 한번 뜯어봤다. 아래는 기존에 사용하던 API 에러 핸들링을 더 잘해보기 위해서 고민한 내용이다.

고민하게 된 계기

React Query만 잘 도입하면 되겠다 싶었는데, 세션에 대한 처리가 필요했다. 기존에는 세션에 관련된 커스텀 훅을 만들고 여기에 API 응답을 넣어서 처리가 될 수 있도록 했는데 React Query를 도입하면서 동일하게 처리할 수 없었다. React Query에서는 이를 onError 옵션을 통해 처리할 수 있도록 하고 있는데 기존 세션 만료 응답은 200으로 오고 있어 에러로 처리할 수 없었다. 이를 select 등의 옵션에서 처리하는 것은 가독성도 헤쳤고 시간이 많이 흐른 뒤에 의도를 파악하기 힘들어 유지보수에도 악영향을 끼칠 것이라는 생각이 들기도 했다. 그래서 여러가지 시도를 통해 문제를 파악하다가 결국 API 핸들러 레벨부터 수정을 해보기로 했다. 

목표

크다면 큰 작업이 될 예정이었기 때문에 간단하게 목표를 통해 제한범위를 정해서 진행해보기로 했다. 

1. 기존 API 핸들러를 그대로 두되, 새로운 API 핸들러를 만들고 이용한다.

2. useApiError를 통해 공통 에러 관련 로직을 관리해 유지보수가 편하도록 한다.

3. 필요한 경우 사용하는 컴포넌트에서 추가 로직을 주입할 수 있도록 한다.

API 핸들러 만들기

기존 API 핸들러의 기본 로직은 아래와 같았다. 

export const receive = (promise: AxiosPromise<any>): Promise<ApiResponse> =>
    new Promise((resolve, reject) => {
        promise
            .then((response: AxiosResponse) => {
                if (
                    응답 결과 === "A" || 
                    응답 결과 === "B" ||
                    응답 결과 === "C" ||
                    응답 결과 === "D" ||
                    응답 결과 === "E" ||
                    !응답 결과

                ) {
                    const data = response.data;

                    const headers = response.headers;

                    const apiResponse: ApiResponse = {
                        result: ApiResult.OK,
                        data,
                        headers,
                    };

                    resolve(apiResponse);
                } else {
                    // 공통 error handle 처리
                    const apiError: ApiError = {
                        result: ApiResult.UNKNOWN_ERROR,
                        message: 'unknown error.',
                        data: response.data,
                    };

                    // 에러 내용을 주입하는 로직

                    reject(apiError);
                }
            })
            .catch((reason: AxiosError<{ additionalInfo: string }>) => {
                const apiError: ApiError = {
                    result: String(reason?.response?.status),
                    message: reason.message,
                    data: reason?.response?.data,
                };

                reject(apiError);
            });
    });

기존 API의 경우 모든 응답이 200으로 왔고 따로, 응답 안에서 코드를 보내주는 형식이었다. 그렇기 때문에 200 응답이 온 경우에 코드의 조건을 비교하고 일치하지 않으면 에러를 발생시키도록 되어 있었다. 하지만, API 응답 구조가 변경되면서 수정이 필요했는데 급하게 프로젝트를 진행하기 위해서 !응답결과 라는 조건을 통해서 사용할 수 있도록 했었다. 

이렇게 사용하다보니 조건이 추가되는 경우마다 A,B,C,D 늘어나면서 알아보기 어려워지고 사이드 이펙트가 두려워 쉽게 수정도 하기 어려운 상황이 되고 있었다. 아예 뜯어 고칠 수 있었다면 좋았겠지만 이를 위해서는 여러 영역에서 대대적인 수정이 필요하게 되어 우선 새로운 API 핸들러를 만들어 보았다. 

export const axiosRequest = (
    promise: AxiosPromise<any>
): Promise<AxiosResponse> =>
    new Promise((resolve, reject) => {
        promise
            .then((response: AxiosResponse) => {
                const data = response?.data;

                if (
                   (!응답결과 || 응답결과 === "200") && (세션관련 처리)
                ) {
                    const apiResponse: AxiosResponse = response;

                    resolve(apiResponse);
                } else {
                    // 여기에 공통 error handle 처리
                    const apiError: ApiError = {
                        result: ApiResult.SESSION_OUT,
                        message: '세션 정보가 없습니다.',
                        data: response.data,
                    };

                    reject(apiError);
                }
            })
            .catch((reason: AxiosError<{ additionalInfo: string }>) => {
                const apiError: ApiError = {
                    result: String(reason?.response?.status),
                    message: reason.message,
                    data: reason?.response?.data,
                };

                reject(apiError);
            });
    });

보이는 것처럼 눈에 띄는 엄청난 변화는 없지만, 우선 지저분한 여러 조건들을 삭제하였고 세션 관련 처리 로직을 추가하였다. 이제 세션이 없는 경우에 200이 아닌 403 에러를 받을 수 있게 되었다. 욕심을 부려서 대대적으로 수정을 할 수도 있지만 이번 목표가 모든 영역을 아우르는 것이 아니었기 때문에 이후 작업을 진행했다. 

에러 흐름 파악하기

API 핸들러를 새로 만들었기 때문에 이제 이를 이용하면서 진행할 공통 에러 처리 로직을 만들 차례였다. React를 사용하는 프로젝트이기 때문에 어디서든 사용할 수 있도록 커스텀훅을 이용했다. 

우선, 회사 프로젝트에서 사용되는 에러의 종류는 이렇다. 

1. 기존 API의 경우 모든 응답은 200, 상황에 따라 result를 통해 에러 코드를 보낸다. (10003, 10004 등)

2. 신규 개발되는 API 경우 200, 400 등의 상태로 응답이 오며, 필요한 경우에 errorCode를 보낸다.

3. 필요한 경우, 동일한 errorCode라고 해도 다른 errorMessage를 가지는 경우가 있다.

기본적으로 2번과 3번의 상황에 사용될 수 있도록 아래의 흐름으로 로직을 구성했다. 관련하여 화해(버드뷰)의 블로그에서 아이디어를 얻을 수 있었다. 

그림에서 보이는 것처럼 에러의 처리는 아래 순서로 진행하기로 했다. 

1. API 요청에서 에러가 발생하는 경우 먼저, 상태코드를 확인한다.

2. 해당하는 상태코드에 추가적인 에러코드가 없다면 상태코드로 분기하여 관련 로직을 수행한다.

3. 해당하는 상태코드에 추가적으로 에러코드가 있다면 상태코드로와 에러코드를 이용하여 분기한 후 관련 로직을 수행한다.

실제 구현

useApiError 커스텀 hook

import { useCallback } from 'react';

type HandlersType = {
    [status: number | string]: any;
};

export const useApiError = (handlers?: HandlersType) => {

    const handle403 = () => {
        // 세션 만료 팝업 호출
    };

    const handle500 = () => {
        // 500 상태 관련 로직
    };

    const handleDefault = () => {
        // 기본 에러 처리 로직
    };

    // 기본적으로 처리될 수 있는 에러 핸들러
    const defaultHandlers: HandlersType = {
        403: {
            default: handle403,
        },
        500: {
            default: handle500,
        },
        default: handleDefault,
    };

    const handleError = useCallback(
        error => {
            const httpStatus = error.result;
            const errorCode = error.data.errorCode;
            const errorMessage = error.data.errorMessage;

            switch (true) {
                case handlers &&
                    !!handlers[httpStatus]?.[errorCode]?.[errorMessage]:
                    handlers![httpStatus][errorCode][errorMessage]();
                    break;

                case handlers && !!handlers[httpStatus]?.[errorCode]:
                    handlers![httpStatus][errorCode](error);
                    break;

                case handlers && !!handlers[httpStatus]:
                    handlers![httpStatus].default(error);
                    break;

                case !!defaultHandlers[httpStatus][errorCode]:
                    defaultHandlers[httpStatus][errorCode]();
                    break;

                case !!defaultHandlers[httpStatus]:
                    defaultHandlers[httpStatus].default();
                    break;

                default:
                    defaultHandlers.default();
            }
        },
        [handlers]
    );

    return { handleError };
};

useApiError 라는 커스텀 hook 안에서 공통으로 처리될 수 있는 로직을 정의했고 이를 switch를 이용해서 우선순위에 따라서 처리될 수 있도록 했다. 우선순위는 아래와 같다. 

1. 특정 컴포넌트에서 정의한 핸들러이며, errorMessage에 따라서 분기가 필요한 경우

2. 특정 컴포넌트에서 정의한 핸들러이며, errorCode에 따라서 분기가 필요한 경우

3. 특정 컴포넌트에서 정의한 핸들러이며, 상태 코드에 따라서 분기가 필요한 경우

4. hook에서 정의된 핸들러이며, 상태코드 및 errorCode에 따라서 분기가 필요한 경우

5. hook에서 정의된 핸들러이며, 상태코드에 따라서 분기가 필요한 경우

기본적인 사용법

const useCustomQuery = () => {
    const {handleError} = useApiError();

    return useQuery([queryKey], fetchApi, {
        onError: handleError
    })
}

export default useCustomQuery;

특별한 추가 로직이 없는 경우에는 handleError를 바로 이용할 수 있다. 이를 통해서 API 통신을 하는 로직에 복잡한 에러 로직이 들어갈 필요가 없고, 굳이 노출할 필요가 없는 부분을 추상화 시킬 수 있다. 만약, 특정 동작을 추가하고 아래처럼 주입할 수 있다.

핸들러 주입하기

const useCustomQuery = () => {
    const {handleError} = useApiError({
         400: {
            [에러코드]: () =>
                openFailedToast({ message: '잘못된 정보입니다.' }),
        },

    });

    return useQuery([queryKey], fetchApi, {
        onError: handleError
    })
}

export default useCustomQuery;

기본적으로 handleError 의 경우에 defaultHandler에 정의 된 로직을 처리하도록 되어있지만 hook을 호출하는 시점에서 핸들러를 주입하면 이를 이용할 수 있다. 따라서, 추상화 레벨은 유지하면서 사용하는 컴포넌트의 상황에 따라서 필요한 로직을 주입할 수 있게 된다. 

마치며

기존에는 API 관련 함수를 볼 때 여러가지 에러 처리 로직이 뒤섞여 있었고 이 때문에 복잡한 구현 내용을 파악해야만 했다. 특히, 한 API에서 여러가지 에러 코드를 다뤄야 하는 경우에는 복잡하다보니 실수도 자주 발생했다. 때문에 이를 쉽게 만들어 줄 수 있는 방법을 고민하고 있어 찾는 도중 화해(버드뷰)에서 작성해주신 글을 보고 좋은 아이디어를 얻을 수 있었다. 기존의 API에도 모두 적용할 수는 없었지만 앞으로의 개발에서는 이를 사용해서 팀원들이 편하게 사용할 수 있으면 좋겠다. 그리고 앞으로의 유지보수에 기여가 됐으면 한다. 

참고 : 화해(버드뷰) - React Query와 함께하는 API에러 처리 설계하기

기업협업을 진행하던 당시에 면접을 보고 온 동기가 useEffect 대신할 수 있는 라이브러리가 있다는 말을 했다. 그 당시에는 무엇인지 제대로 몰랐지만 얼마 후 그 라이브러리가 React Query 라는 것을 알게 됐다. 물론, useEffect를 대신하는 라이브러리라고 보기에는 어렵지만 useEffect를 이용해 데이터를 가져오지 않아도 되는 것은 맞았다. 이후 우아한 테크세미나를 통해 React Query에 대해서 발표를 듣기도 했지만 간단한 테스트 정도만 진행해보고 제대로 도입을 고민해보지는 못했다. 하지만, 데이터를 잘 다루기 위해 Redux를 사용하고, 비동기를 잘 처리하기 위해 여러가지 미들웨어까지 도입하고 있자면 절실히 다른 방법을 찾고 싶은 생각이 들곤 했다. 상태 관리 라이브러리라는 이름과는 다르게 Redux에는 온갖 비동기 관련 로직들이 가득해지곤 했으니까. 

아래는 React Query 공식 사이트에서 볼 수 있는 React Query의 소개 문구이다. 

Fetch, cache and update data in your React and React Native applications all without touching any "global state".

즉, 데이터를 가져오고, 캐시하고, 동기화하고 업데이트 하는 작업을 전역 State 없이 수월하게 할 수 있도록 해주는 라이브러리이다.

도입하게 된 계기

우선, React Query의 특징을 정리해보면 이렇다.

1. Server State와 Client State라는 개념을 분리하여 프론트엔드에서 Server State를 다루는 방법을 재정의하고 있다. 

2. Server State를 다루는 방법에 있어 SWR(Stale-While-Revalidate) 전략을 통해 해결하고 있다. 

3. useQuery와 같은 Hook 인터페이스로 제공되기 때문에 도입이 어렵지 않고 기존 방식보다도 간결하게 사용할 수 있다.

React Query가 좋다는 건 알겠는데, 그래서 굳이 기존의 방식을 벗어나 새롭게 도입해야하는 이유는 무엇일까?

우선, 나는 기존에 Server State와 Client State를 혼용하며 관리했다. 특히 Server State의 경우에는 클라이언트가 아닌 서버에서 관리되고 변경되는 상태였기 때문에 언제나 "out of date" 될 수 있는 위험이 있었다. 그렇기 때문에 지속적으로 데이터 업데이트 및 관리, 캐싱 등에 대해서 고민을 할 필요가 있었다. 이를 해결하기 위해 Redux 등을 사용하면 무수한 미들웨어와 많은 보일러 플레이트 코드가 따라오곤 했다. 

심지어, 서버의 데이터를 가져오고 업데이트 하는 과정에서 사용자의 UX를 위해 로딩 등의 상태를 처리하기 위해서 추가적으로 Client State 를 늘려야만 했다. 아래처럼.

const App = () => {
  const [isLoading, setIsLoading] = useState();


  const fetchData = async () => {
      setIsLoading(true) // 로딩 상태로 변경하고


    try {
      const data = await apiFunction()

      if(data) {
          setIsLoading(false); // 로딩을 끝낸다.
        // ... 이후 로직
      }
    }
    catch(error) {
        console.log(error);
        setIsLoading(false);
    }
  }
}


export default App;

페이지가 늘어날 수록, 기능이 많아질 수록 Loading 등과 관련 된 상태를 개발자가 직접 구현하고 핸들링 해야하는 부담은 커지게 된다. 이는 휴먼 에러가 생길 가능성이 늘어난다는 말과 같다. 실제로 개발을 진행하며 여러가지 상태를 관리하는 과정에서 로딩 관련 상태를 놓치는 경우가 생겨 무한 로딩을 하게 되는 경우가 발생했다. 

이러한 고민들을 React Query는 각종 보일러 플레이트나 러닝 커브 없이 기존에 하던 방식과 유사하고 더욱 간결하게 해결할 수 있도록 해준다. React Query과 어떻게 이를 해결하고 있는지 살펴보자. 

 사용 방법

간단한 예시를 통해서 리액트 쿼리의 사용 방법을 알아보자.  

설치법

npm i react-query // npm 사용

yarn add react-query // yarn 사용

초기 설정

import {QueryClientProvider, QueryClient} from "react-query";

const queryClient = new QueryClient();

function App() {
  return (
      <QueryClientProvider client={queryClient}>
          {...}
      </QueryClientProvider>);
}

React Query는 데이터를 전역 상태처럼 사용할 수 있도록 제공하고 있기 때문에 이를 위해 Provider로 전체 앱을 감싸줘야 한다. 이후에는 사용하고자 하는 곳에서 useQuery를 통해 데이터를 받아올 수 있다. 

useQuery

데이터를 가져오는 경우에는 useQuery hook을 사용하면 된다. useQuery는 아래와 같은 구조를 가지고 있다. 

// 일반적
const responseData = useQuery(쿼리 키, 비동기 함수, 옵션);

// 구조분해 할당
const {data, isLoading, isFetching} = useQuery(쿼리 키, 비동기 함수, 옵션);

쿼리 키의 경우에는 string이나 배열로 전달할 수 있고 배열로 전달하는 경우에는 ["key", "first"], ["key", "second"] 와 같이 "key" 가 동일하다고 해도 다른 쿼리로 인식된다. 더 확실한 관리를 위해서 배열의 형태로 전달하는 것을 추천한다. 

실제 사용법은 아래와 같다. 실제로 이번 스프린트에 사용되는 코드에 적용된 모습을 수정했다.

const useListQuery = (options?: any) => {
    const { openSuccessToast, openErrorToast } = useToast();

    const queryClient = useQueryClient();

    const { data, isLoading } = useQuery(["list"], getList, {
        onError: () => {
            openErrorToast({});
        },

        onSuccess: () => {
            openSuccessToast({});
        },

        refetchOnWindowFocus: false,
    });

    const invalidateClientListQuery = () => {
        queryClient.invalidateQueries('list');
    };

    return {
       data,
       isLoading,
    };
};

export default useListQuery;

React Query의 TkDodo는 쿼리를 컴포넌트 옆에서 관리하자고 제안했다. (링크 : Effective React Query Keys) 폴더 구조까지 적용하지는 않더라도 커스텀 훅으로 분리하여 쿼리를 관리하는 부분은 컴포넌트와 데이터 통신의 유착을 줄이고 유지보수에도 도움이 될 것이라고 생각한다.  위의 코드에서 알 수 있듯이 isLoading이나 isFetching 등의 상태를 제공하고 있기 때문에 추가로 상태를 만들어 관리할 필요가 없으며 데이터를 위한 상태를 만들 필요도 없다. data를 이용해 바로 사용하면 된다! 

만약 서버로 받은 데이터를 가공해야 한다면? options 중에서 select를 사용할 수 있다. 

const useCountryListQuery = (lang: string) => {
    const queryClient = useQueryClient();

    const { data } = useQuery(
        ['countryList', lang],
        () => getCountryList(lang),
        {
            select: res => {
                return {
                    ...res,
                    data: res.data.body.map(item => {
                        return {
                            ...item,
                            label: item.name,
                            value: item.name,
                        };
                    }),
                };
            },
            refetchInterval: 60 * 60 * 1000,

            refetchOnWindowFocus: false,
        }
    );

    const invalidateCountryListQuery = () => {
        queryClient.invalidateQueries('countryList');
    };

    return {
        countryList: data?.data,
        invalidateCountryListQuery,
    };
};

export default useCountryListQuery;

위의 코드처럼 사용하면 데이터를 가공하여 관리할 수 있다. 한 가지 주의할 점은 onError, onSuccess, select의 경우에 enabled 등의 옵션과 상관 없이 useQuery가 호출되는 경우 무조건적으로 호출된다는 점이다. 처음에는 이를 몰랐고 select 안에서 사용되는 modal이 여러 번 반복되는 현상을 겪게 됐다. API 호출은 1번만 정상적으로 이뤄지고 있었기 때문에 다른 원인이라 생각해서 한참을 헤매고 나서야 이유를 알 수 있었다.

useQuery의 여러 옵션은 공식문서 를 통해 볼 수 있지만 몇가지 중요한 옵션은 짚고 넘어가고자 한다. 

✅ cacheTime : 어느 시점까지 메모리에 데이터를 저장해 캐싱할 것인지를 결정하는 옵션이다. 기본값은 5분이다. (단위 ms)
✅ staleTime : React Query에서는 데이터를 요청한 쿼리를 stale하다고 판단하는데 이를 결정하는 시간을 결정하는 옵션이다. 기본 값은 0이다.
     (✨ cacheTime 이나 staleTime 둘 중에 하나라도 만료가 되면 데이터를 재요청하게 된다.)
✅ refetchOnMount : 컴포넌트가 마운트 되는 경우에 새로운 데이터를 가져온다. 기본값 true이다.
✅ enabled : false로 설정할 경우 컴포넌트가 마운트 되어도 데이터를 가져오지 않는다. 기본값은 true이다.
     (주로 동기적으로 데이터를 가져오고 싶은 경우에 사용할 수 있다.)
✅ refetchOnWindowFocus : 브라우저로 포커스가 옮겨진 경우에 새로운 데이터를 가져온다. 기본값은 true이다.
     (웹뷰 등을 사용한다면 이를 이용해 사용성을 개선할 수 있다.)

여기서 cacheTime 과 staleTime 의 경우에는 React Query를 사용할 때 중요한 옵션이라고 생각한다. 캐싱 관련 기능을 손쉽게 사용할 수 있도록 도와주는 옵션들이기 때문에 이를 이용해 효율적으로 Server State를 관리할 수 있다. 

useMutation

서버의 데이터를 업데이트하는 작업을 진행하는 경우에는 useMutation 훅을 사용할 수 있다. 

const { mutate: addList, isLoading } = useMutation(addData, {
    onSuccess: () => {
        invalidateListQuery();
        openSuccessToast({ message: '저장되었습니다.' });
    },
    onError: () => {
        openErrorToast({});
    },
});

const handleConfirm = async () => {
    addList(data);
}

useMutation 역시 isLoading 이나 isError 등의 반환 값을 받아 처리할 수 있으며 추가로 mutate 메서드를 받을 수 있다. 이를 이용해서 서버의 데이터를 업데이트 할 수 있다. 이 때, 서버의 데이터를 업데이트 한 이후에 캐싱된 데이터도 새롭게 업데이트를 해야 하는데 invalidateQueries 메서드를 통해서 쉽게 해결할 수 있다. 

// 어떤 키도 전달하지 않으면 캐시된 모든 쿼리를 무효화 할 수 있다.
queryClient.invalidateQueries()

// 키를 전달한 경우에는 해당 키를 가진 쿼리를 무효화 한다.
queryClient.invalidateQueries('list')

추가로 onMutate 옵션을 통해서 mutate 함수가 실행되기 전에 필요한 로직을 작성할 수도 있다. 

마무리

가장 최근에 사용했던 코드에 React Query를 적용해보면서 굉장히 많은 상태를 줄일 수 있다는 점을 느꼈다. 특히, 간단하게 사용을 해봤음에도 캐싱이나 여러가지 상태를 제공해주는 것의 강력함을 느낄 수 있었다. 특히, 기존의 많은 통신들을 React Query를 통해서 개선할 수 있다면 Redux store의 영역을 줄이고 modal의 open/close 의 상태나 다른 UI 관련 상태에만 집중할 수 있어 더욱 깔끔하게 코드를 개선할 수 있겠다는 생각이 들었다. 물론, 도입을 해보면서 Api 핸들링 부분이 기존과 맞지 않는 부분이 있어 어려움이 있었고 persist 기능 등 더욱 살펴볼 지점은 분명히 있었지만 매우 매력적인 도구라는 것은 분명했다. 다음에는 React Query를 프로젝트에 적용하면서 겪었던 어려움을 해결하는 과정에 대해서 기록해보고자 한다.

현재, 현장에서 일하는 직원들을 위한 협업툴을 서비스하는 회사에서 개발을 하고 있다. 입사 초기에는 기존 서비스를 리액트로 마이그레이션 하는 작업을 천천히 맡아 진행하고 있었는데, SAAS 부분을 강화하는 프로젝트를 진행하게 되면서 운영 어드민을 새롭게 리드해서 만들게 되었다. 운영 어드민의 경우에 여러가지 핵심 비지니스 로직들이 많아서 부담이 되는 부분도 있었지만, 다양한 데이터를 다뤄보고 비지니스 로직을 구현할 수 있어 즐겁게 진행하는 중이다. 그 중에 결제 관련 기능을 구현하면서 인보이스, 청구서 다운로드 기능을 구현하게 됐다. 기존에 URL을 통해서 쉽게 다운로드를 구현할 수 있구나 싶었는데, 전과는 다른 방법을 이용해야 했기 때문에 기록으로 남겨두려고 한다. API 호출했는데 이상한 문자만 와요! 라는 부끄러운 소리를 했던 기억을 되돌려보며... 똑똑히 기억해야겠다.

Blob?

부끄럽게도 그 동안 짧은 개발기간을 보내오는 동안 blob을 다뤄본 기억이 없었다. console을 통해 만나본 response 속에 이상한 문자가 바로 blob의 형태이다. blob은 Binary Large Object의 약자로 이름에서 예상이 되는 것처럼 바이너리 형태의 큰 객체(이미지, 비디오 등)를 담을 수 있다. 자바스크립트에서는 이를 사용하기 위해 new Blob을 사용할 수 있다.

어떻게 적용할까?

우선 blob을 이용하기 위해서는 Axios에서 responseType을 설정해야 한다.

export const downloadFile = async (
) => {
    return receive(
        client(
           url,
            {
                method: 'GET',
                responseType: 'blob',
            }
        )
    );
};

위처럼 responseType 을 지정한 후에는 response를 이용해서 가공을 진행하면 된다.

// Blob은 배열 객체 안의 모든 데이터를 합쳐 blob으로 반환하기 때문에 []안에 담는다!
const blob = new Blob([res.data])

// window 객체의 createObjuctURL을 이용해서 blob:http://~~~ 식의 url을 만들어 준다.
const fileUrl = window.URL.createObjectURL(blob);

// link 안에 위에서 만든 url을 가지고 있는 a 태그를 만들고 보이지 않도록 해준다.
// a 태그는 노출하지 않고 자동으로 클릭되도록 할 예정! 
const link = document.createElement('a');
link.href = fileUrl;
link.style.display = 'none';

지금까지의 과정을 간단히 설명하자면 blob 객체를 만들고 이를 통해서 url을 생성한다. 이 url을 가지고 있는 a태그를 만들고
이를 클릭해서 실행되도록 하면 된다. 다만, 파일 이름을 지정해줘야하는 단계가 남아있는데 나의 경우에는 파일 이름이 header에
"content-disposition" 를 통해 담겨오기는 했지만 인코딩 되어 있었기 때문에 디코딩이 필요했다. 코드는 아래와 같았다.

// response의 headers에 있는 content-disposition을 찾아서 디코딩 한다.
const injectFilename = (res: ApiResponse) => { 
      const disposition = res.headers['content-disposition'];

      const fileName = decodeURI(
        disposition
          .match(/filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/)[1]
          .replace(/['"]/g, '')
      );
        return fileName;
    };

마지막으로, a 태그의 다운로드 프로퍼티에 만들어 준 이름을 넣어주고 클릭되도록 하면 된다.

link.download = injectFilename(res);

document.body.appendChild(link);
link.click();
link.remove();

window.URL.revokeObjectURL(fileUrl);

위의 코드를 적용하면서 처음에는 에러가 많이 났다. 파일 이름도 테스트라고 입력 했다가 확장자를 제대로 입력하지 않아서 txt 파일로 받아지기도 하고
파일을 열어보니 알 수 없는 문자가 가득한 외계어의 파일이 열리기도 하고... 이름도 완벽하고 확장자도 완벽했지만 자꾸만 열 수 없다는 알림이 뜨면서 확인이 되지 않기도 했다.

이상한 문자의 파일이 자꾸 뜨는 오류의 경우는 파일 이름을 정확하게 입력하면서 해결이 됐고, 파일이 손상되서 열 수 없는 이유는 다른 코드를 수정하면서
responseType을 지워버렸기 때문이었다. 그렇게 몇 번의 시도 끝에 정확하게 원하는 파일을 다운로드 할 수 있었다.

파일을 다운로드 하는 방법이 위와 같은 방법만 있지는 않다. 중간에 다른 방법을 이용해서 시도했고 성공하기도 했는데 나는 사용하지 않았지만 간단히 소개만 해보려고 한다.

간편한 방법

나는 리액트를 사용하여 프로젝트를 진행하고 있고 API 통신의 경우 Axios를 사용하고 있기 때문에 form의 action를 사용하고 싶지 않았다. 하지만 form의 action을 사용하면 조금 더 간단하게 시도해 볼 수 있다.

<form action={url} method="get">
  <button type="submit">버튼</button>
</form>

위와 같이 시도하면 된다. form의 action을 이용하기 위해서는 submit 이벤트를 이용해야 하고 이를 통해 새로고침이 발생하기 때문에 나는 target="_blank"를 통해서 새 창이 열리도록 했고 다운로드를 받을 수 있었다.

이 방법을 시도해보면서 반성을 하게 됐는데, 그 동안 form에 있는 action의 기능을 전혀 사용해보지 않았다는 점이었다. react의 경우에 주로 onClick이나 onSumbit을 이용하면 거의 모든 기능 구현에 문제가 없기도 했기 때문에 고려조차 하지 않았는데, 때로는 훨씬 적은 코드로도 동일한 기능을 수행할 수 있다는 점을 알게 됐다.

물론, 새로고침 때문에 새 창을 이용하거나 API에 관련 된 로직 등을 흩어지도록 만들고 싶지 않아서 통일성을 위해 onClick 이벤트를 이용해 기능을 구현했지만 다른 문제를 접근할 때 편하고 익숙한 방법만 찾고 있지는 않는지 다시 한 번 생각해보게 된 계기가 됐다. 고작 5-6개월 정도 스타트업 개발자로서 즐겁게 일하고 있는데, 앞으로도 많은 문제를 만나고 이겨내면서 오래 오래 개발을 해나가고 싶다. 그 기간 동안 고이기 보다는 신선하고 효율적인 방법에 대해서 많이 고민해 볼 수 있다면 좋겠다.

전체 코드

아래는 편하게 볼 수 있도록 전체 코드이다.

const onClick = () => {
  downloadFile().then(res => {
    const blob = new Blob([res.data]) 

    const fileUrl = window.URL.createObjectURL(blob);

    const link = document.createElement('a');
    link.href = fileObjectUrl;
    link.style.display = 'none';

    const injectFilename = (res: ApiResponse) => { 
      const disposition = res.headers['content-disposition'];

      const fileName = decodeURI(
        disposition
          .match(/filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/)[1]
          .replace(/['"]/g, '')
      );
        return fileName;
    };
    link.download = injectFilename(res);

    document.body.appendChild(link);
    link.click();
    link.remove();
  })
}

React를 사용하여 프로젝트를 진행하면서 많은 고민이 되는 부분 중에 하나는 바로 어떤 값을 state 로 설정하여야 하는지에 대한 고민일 것이다. 만약 한 페이지 내에서 사용하는 모달창이 5개가 있고 이를 boolean 값을 통해 관리한다면 5개의 비슷한 state 가지고 있어야한다. 이는 매우 낭비라는 생각이 들었기 때문에 이를 개선해보고 싶었다.

어떤 방법이 좋을까?

먼저, 어떤 값을 이용하면 5개의 상태값을 하나로 줄일 수 있을 지 고민했다. 이는 간단했는데, 바로 boolean 값이 아닌 설명하는 내용을 통해서 관리하면 되는 문제였다.

예를 들어 삭제 관련된 Modal 의 경우에는 delete 등의 이름을 부여했다. 그렇다면 이제 삼항연산자 등을 이용해서 이름에 맞는 Modal 이 뜨도록 하면 된다. 하지만, 문제는 Modal 이 2개가 아닌 여러 개라는 점이었다.

Switch 문 대신 객체 사용

각 케이스마다 해당하는 로직이 구현되도록 하는 방법으로는 switch 문이 있다. 하지만, switch 문의 경우에는 변수에 할당할 수 없기 때문에 이를 JSX 내에 사용하지 않는다. 그렇기 때문에 다른 방법이 필요한데, 이 때 객체를 사용할 수 있다.

 const MODAL = {
    delete: (
      <DeleteModal
        id={openModal.id}
        handleCancel={handleCancel}
        updateComment={updateComment}
      />
    ),
    put: (
      <ToMyBooksModal
        handleCancel={handleCancel}
        handleMakeButton={handleMakeButton}
        libraryList={libraryList}
        handleLibrary={handleLibrary}
        onPutBook={onPutBook}
      />
    ),
    make: (
      <LibraryModal
        handleCancel={handleCancel}
        handleLibraryName={handleLibraryName}
        libraryName={libraryName}
        addLibrary={addLibrary}
      />
    ),
  };

위는 Modal 을 한 번에 가지고 있는 객체인 MODAL 이다. 이를 통해서 각 상태값이 키값으로 들어올 때 원하는 Modal 를 불러올 것을 예상할 수 있다.

 <Potal>
   <ModalLayout>{MODAL[openModal.type]}</ModalLayout>
 </Potal>

위의 코드처럼 사용하면 Potal 을 통해서 외부 DOM에 렌더링 하면서 이전에 작성한 <ModalLayout> 의 children 으로 Modal 이 들어가도록 할 수 있다. 반복을 줄일 수 있고 코드로 훨씬 간결해 진 것을 알 수 있다.

프로젝트를 진행하면서 꽤 긴 시간을 사용했던 드래그 슬라이드에 대해서 정리해보고자 한다. 배워가는 단계에서 작성한 코드이기 때문에 구현에 초점을 맞췄다는 점을 짚고 넘어갔으면 한다.

드래그 슬라이드

위의 모습처럼 마우스를 통해 드래그를 했을 때 좌우로 움직이는 슬라이드이다. 단순히 onDrag 이벤트를 사용하면 되는 것이 아닌가 싶을 수 있지만 drag 이벤트를 사용하는 경우에 잔상이 생겨서 원하는 결과물과는 달랐다. onDrag 이벤트를 사용하면서 잔상을 없애는 방법을 여러가지 찾아봤지만 드래그를 제한하는 방법들이 대부분이었다. 그래서 아예 방향을 틀어서 mouse 관련 이벤트를 통해서 이를 구현했다.

1. 마우스 클릭 관련 이벤트

const handleScroll = (e, scroll) => {
    switch (scroll) {
      case 'start': // 마우스 버튼 누르는 경우
        setOriginX(e.clientX);
        setIsScroll(true);
        break;
      case 'end': // 마우스를 버튼 누르기 중단
        setAfterX(position);
        setIsScroll(false);
        break;
      case 'leave': // 마우스가 영역을 벗어난 경우
        setIsScroll(false);
        break;
      default:
        break;
    }
  };

먼저 드래그를 하고 있는 상태를 확인하기 위해서 onMouseDown 과 onMouseUp 이벤트를 사용했다. 이 때 여러 개의 함수를 만들기 보다는 스크롤 여부를 추적하는 한 개의 함수를 사용하기를 원했고 switch 문을 통해서 이를 작성했다.

여기서 originX 는 드래그를 시작하는 지점의 위치를 저장할 변수이고 afterX 는 드래그를 중단한 경우에 마지막 위치를 저장할 변수이다. 이를 통해서 중간에 드래그를 멈췄다가 다시 시작하는 경우에 초기화 되지 않도록 했다.

2. 스크롤 관련

const handleSlide = e => {
    const newPosition = e.clientX - originX + afterX;
    const hiddenLength = e.currentTarget.offsetWidth - 166 * BOOKS.length;
    if (isScroll === false) {
      return;
    }

    newPosition < 10 && newPosition > hiddenLength && setPosition(newPosition);
  };

이제 마우스가 움직일 때 따라서 드래그 될 수 있도록 onMouseMove 이벤트를 이용해서 위치를 변동할 수 있도록 했다. 이 때, 좌우 스크롤의 경우에 빈 공간을 보여주지 않도록 제한사항을 두도록 했다.

구현 화면

이를 구현하는데 꽤 많은 시간을 썼다. 특히, 초기화 되는 부분에서 애를 많이 썼던 것 같다. 구현 방법을 구상하고 이를 코드로 옮기는데 얼마나 부족한지 많이 깨닫게 된 기능이었다. 누군가가 비슷한 기능을 만들 때 조금은 도움이 됐으면 하는 마음으로 코드를 남겨본다.

TomorrowsNotebook - Frontend Github TomorrowsNotebook - Backend Github 시연 영상 - 유튜브

프로젝트 소개

'밀리의 서재' 어플리케이션을 벤치마킹하여 전자책 구독 플랫폼 서비스를 구축했습니다. 애자일 방법론을 채택하여 연휴를 제외하고 총 2주 간 스프린트 방식으로 프로젝트를 진행했습니다. 사용자에게 편리하고 유용한 서비스를 제공할 수 있는 방법을 고민하고 실행에 옮기는 것을 기초 목적으로 삼았으며, 효율적인 아키텍처 구축을 위해 노력했습니다.

백엔드팀에서는 사용자 중심의 다양한 서비스를 제공하기 위해 효율적인 데이터 모델링 방안을 고민했습니다. 최적화된 데이터베이스 사용을 목적으로 장고 ORM을 사용하였고, AWS의 RDS, EC2, S3버킷 등을 사용하여 시스템 아키텍쳐를 설계했습니다. 각 기능에 대해 유닛테스트를 진행하여 여러 환경 변수에 대한 안정성을 확보했습니다.

프론트엔드팀에서는 React Hooks와 Styled-Component, 라이브러리 등을 이용하여 사용자의 흥미를 이끌어낼 수 있는 UI/UX를 구현했습니다. 직관적인 구조 파악과 재사용성을 염두에 두고 컴포넌트를 분리시켰으며, 동시에 API 통신으로 받은 데이터의 효율적 전달성을 확보했습니다.

제작 기간

2021.09.13(월) ~ 2021.10.1(금) (연휴기간 제외)

기술 스택

*✨ 프론트엔드(3명) : 강연옥, 조성환, 주철진 *

• JavaScript(ES6+)
• React
• Styled Component
• Styled-icon
• React-pdf

*🔥 백엔드(3명) : 이무현, 신우주, 박지원 *

• Django
• Python
• MySQL
• Aquery

공통 협업 도구

• Slack
• Notion
• Trello
• Git
• Github
• Zoom

주요 구현 사항

📕 는 내가 구현한 기능에 표시했다.

✅ 로그인 페이지

✨ 로그인 페이지 레이아웃 ✨ 카카오 API를 이용한 소셜로그인 구현 ✨ 로그인 성공시 페이지 이동 구현

✅ 메인 페이지

📕 메인페이지 레이아웃 구현 📕 메인페이지 배너 캐러셀 슬라이드 구현 📕 책 리스트 스크롤 슬라이드 구현 📕 메인페이지 API 통신을 이용한 책 추천 서비스 구현(최신, 출판사별) 📕 상세페이지로 동적라우팅 기능 구현

✅ 검색창 페이지

✨ 카테고리별 도서 검색 기능 ✨ 검색 필터링 ✨ 검색어에 따른 결과 미리보기 창 ✨ 검색 결과창에서 도서 클릭 시 상세페이지로 이동

✅ 뷰어 페이지

✨ react-pdf 라이브러리 사용하여 PDF 파일 불러오기 ✨ S3 CORS 에러 및 객체 퍼블릭 설정 변경 통한 디버깅 ✨ 목차 및 해당 페이지로 이동 기능 ✨ 페이지 이동 기능 ✨ 한 쪽 보기, 두 쪽 보기 기능 ✨ 페이지 스크롤 기능

✅ 책 상세 페이지

📕 상세 페이지 레이아웃 및 API 통신(동적라우팅) 📕 리뷰 추가 및 삭제 📕 리뷰 좋아요 기능 📕 내 서재에 담기 기능 📕 책장 만들기 기능 📕 바로 읽기 기능

✅ 나의 서재 페이지

✨ 책장 만들기/삭제 기능 ✨ 읽은 책 담기 기능 ✨ 책장 속 서재 필터링 기능

✨ Project Review

좋았던 점

명확한 기록과 유연한 소통

이번 2차 프로젝트를 진행하면서 부담이 되는 부분이 많았다. 백엔드의 경우에는 데이터 테이블이 복잡할 수 밖에 없었고 프론트의 경우에는 어플리케이션이다 보니 웹으로 전환하는데 어려움이 많을 것으로 예상되었다. 그렇기에 초반에 소통을 하는데 많은 신경을 썼다. 각 화면의 부분들을 캡처해서 보면서 데이터 통신을 어떻게 진행할지 구체적으로 이야기했고 서로의 생각이 다른 부분의 경우에는 여러 사이트들을 직접 보면서 열띤 토론을 이어나갔다. 단지, 누가 편하기 위해서가 아닌 최대한 사용자에게 편한 환경을 제공하고자 하는 토론이었기에 즐겁게 임할 수 있었다. 그렇기에 각 기능들이 만족스러운 결과로 나올 수 있었다.

새로운 기술에 대한 적극적인 도전

프론트엔드의 경우에는 2차 프로젝트를 진행하면서 리액트 Hooks와 Styled Component를 사용해야 했다. 모두 처음 사용해보는 기술들이다보니 초반 레이아웃을 구성하면서 어려움이 많았다. 마치, 처음 JavaScript 를 구현했던 기분이 느껴졌다. 그럼에도 두려움 보다는 흥미로 접근하려고 노력했고 한 줄 한 줄 코드를 늘려나갈 수 있었다. 이번 프로젝트에서 기억에 남았던 부분은 내 코드만 보며 리뷰를 반영했던 것이 아니라 다른 분들의 코드에 달린 리뷰들을 반영해보고자 했던 시도였다. 특히 Potal 에 관련된 내용의 경우에는 우연히 이야기를 듣고 흥미가 생겼었는데 다수의 Modal을 한 페이지 내에서 구현하게 되면서 매우 유용하게 사용할 수 있었다. 단순히, 전에 하던 방식으로 구현하기 보다는 여러 리뷰와 검색을 통해서 새로운 기술을 적극적으로 도입하려고 했던 기억이 인상 깊다.

아쉬운 점

블로커에 대한 대처

프로젝트는 나 혼자만의 문제보다 동료들의 문제를 공유하고 함께 해결해나가는 과정이 중요하다는 생각이 들었다. 이번 프로젝트의 경우 프론트와 백엔드 모두 새로운 도전들이 있었고 그로 인해서 여러가지 블로커들이 생길 수 밖에 없었는데, 이에 대한 해결 과정이 조금은 미숙했다는 생각이 든다. 그러다보니 데이터 통신을 위해 필요한 시간들이 늦어질 수 밖에 없었고 에러를 고쳐나가는 과정이 급할 수 밖에 없었다. 긴밀하게 소통하면서 맞춰나가고 있다고 생각했지만 블로커에 대한 구체적인 대책을 세우는 부분에 있어서는 조금 아쉬움이 남는다. 그럼에도 서로가 어떤 것들을 진행하고 있는지 매일 스탠드업 미팅을 통해서 잘 공유가 됐기 때문에 좋은 결과물을 만들 수 있었다.

추가 구현에 대한 아쉬움

아무래도 아쉬움이 남을 수 없는 부분은 추가 구현에 대한 부분이라고 생각한다. 우리는 밀리의 서재를 모티브로 프로젝트를 진행했는데, 시간이 넉넉하지 못하다보니 필수적인 사항들을 위주로 구현을 진행했다. 그렇기 때문에 사이트를 이용해보면서 느꼈던 불편함에 대해서 정리하고 이를 개선하는 과정에 대한 아쉬움이 남는다. 리뷰 삭제나 상세 페이지에서 책장을 만들고 책을 추가하는 과정에 있어서 불편했던 부분들을 개선하기는 했지만 사이트 전반적으로 사용자가 책을 선택하고 읽는 과정에 대해서 깊이 고민해보고 이를 개선할 수 있었다면 더 좋았겠다는 아쉬움이 남는다. 추후에 코드 리팩토링을 진행하면서 개선할 수 있는 부분이 있는지 고민해보는 과정을 가져보려고 한다.

프로젝트 후기

2주라는 시간이 또 금방 지나가버렸던 2차 프로젝트가 마무리 됐다. 유일하게 어플리케이션을 가지고 프로젝트를 진행해야하기 때문에 걱정을 많이 했었다. 내가 발표했던 사이트였기 때문에 PM의 역할까지 진행을 했었는데, 사실 따로 PM은 없었고 모두가 PM처럼 진행했던 프로젝트라고 생각한다. 모두의 높은 책임감 속에서 어려운 환경에서도 다들 원했던 만큼 구현을 마무리 할 수 있었다.

특히 연휴에 코딩에 집중을 하고 싶어서 카페를 갔었는데 팀원들이 먼저 함께 하고 싶다며 연락이 와서 모일 수 있었다. 누군가가 "해야한다!" 하면서 모인 것이 아니라 "하고 싶다" 라고 모였던 그 순간이 정말 기억에 많이 남는 것 같다. 정말로, 함께하고 있구나 느낄 수 있었다.

명확하게 같은 방향을 바라보며 달려갈 수 있도록 해줬던 연옥님, 맡은 역할을 언제나 최선을 다해서 해결하는 성환님, 어려운 기능을 맡았고 걱정도 많이 하셨지만 행복하게 해낸 지원님, 분위기 메이커 역할만 아니라 새벽까지도 공부하며 원하던 기능을 구현해낸 우주님, 마지막으로 든든하게 뒤를 받쳐주며 어려운 역할을 해주신 무현님까지.

어려운 프로젝트임에도 언제나 웃으면서 즐겁게 할 수 있도록 해준 팀원들에게 정말 감사하다 ✨ 모두가 있었기에 내일배움공책이 있을 수 있었다 🤭

리액트를 사용하면서 SASS 를 사용하게 됐다. 기존의 CSS 만을 사용하는 경우에 비해서 nesting으로 인한 편리함이 마음에 들었다. 또, class 명 역시 비교적 길어지지 않게 작성할 수 있어서 편리했다. 하지만, 여전히 class 명에 대한 고민은 존재했고 동적인 효과를 위해서는 코드를 여러번 작성해야하는 경우도 많았다. 이를 해결하기 위해서 등장한 것이 Styled-Component이다.

Styled Component

Styled Component 는 위에서도 말했던 것처럼 여전히 존재하는 문제들을 해결하기 위해서 고안됐다.

• CSS 클래스 명에 대한 고민은 여전합니다.
  • ex. BEM (.block__element--modifier, button button--state-success)
• 정해진 가이드가 없으면 구조가 복잡해집니다.
• 방대한 스타일 정보로 인한 스크롤 지옥도 여전합니다.
• 여전히 CSS 클래스로 조건부 스타일링을 하고 있습니다.
• CSS 클래스로 조건부 스타일링을 하더라도 동적인 변화를 표현하기에 한계가 있습니다.
  • ex. 1초에 px 값을 1씩 증가 → Inline 스타일에 의존

실제로 SASS 를 사용하면서 편리함을 느꼈지만 여전히 존재했던 문제들이다. 특히 프로젝트를 진행하면서 4가지 버전의 레이아웃을 동적으로 구현했어야 했는데 이 경우에 코드가 상당히 길어지는 일을 겪었다. 또한, 동적인 효과를 위해서 class를 사용하다보니 제약이 생기는 경우도 많았다.

그렇기 때문에 이제는 JS 를 통해서 CSS 까지 함께 할 수 있는 방법인 Styled Component가 나오게 됐다.

사용 예시

const Button = styled.button`
  position: absolute;
  top: 50%;
  ${props => (props.direction === 'left' ? 'left:0' : 'right:0')};
  font-size: 1.5rem;
  transform: translateY(-50%);
`;

위의 경우를 보자. 동일한 Button 이라는 이름을 가진 요소이지만 props 으로 전달받은 direction 에 따라서 다른 스타일을 가지는 것을 알 수 있다.

const List = styled.div`
  position: absolute;
  width: 100%;
  height: 400px;
  padding: 40px 0 0 0;
  background: ${props => props.background};
  opacity: ${props => (props.isCurrentSlide ? 1 : 0)};
`;

또한, 위의 경우처럼 해당 요소의 상태에 따라서 자동으로 동적인 스타일을 부여할 수도 있다. 위 코드를 보면 isCurrentSlide 라는 값을 통해서 현재 보고 있는 슬라이드인 경우에는 opacity 가 1이며 아닌 경우에는 0이 되는 것을 알 수 있다.

Dot Friends - Frontend Github Dot Frineds - Backend Github 시연 영상 - 유튜브

프로젝트 소개

우리는 유명한 커머스 사이트 중에 하나인 라인프렌즈 샵의 클론 코딩을 하게 됐다. 라인프렌즈 샵은 2011년, 모바일 메신저 '라인' 의 스티커 캐릭터로 탄생한 라인프렌즈는 다양한 캐릭터와 아티스트와의 콜라보를 활발히 이어가고 있는 기업으로서 커머스 사이트의 구성과 기본 기능에 대해서 익히기에 적합하다는 생각이 들었다.

제작 기간

21.08.30 (월) ~ 21.09.10 (금)

기술 스택

*✨ 프론트엔드(3명) : 금보배, 박은정, 주철진 *

• HTML/CSS
• JavaScript(ES6+)
• React
• SASS

*🔥 백엔드(3명) : 서동규, 신우주, 김동준 *

• Django
• Python
• MySQL
• Aquery

공통 협업 도구

• Slack
• Notion
• Trello
• Git
• Github
• Zoom

주요 구현 사항

🌈 는 내가 구현한 기능에 표시했다.

✅ 회원가입 페이지

✨ 회원가입 페이지 레이아웃 ✨ API 통신을 이용한 회원가입 구현 ✨ 입력값에 따른 유효성 검사 ✨ 입력 상황에 따라 사용자에게 적합한 내용을 입력하도록 안내 기능 구현

✅ 로그인 페이지

✨ 로그인 페이지 레이아웃 ✨ access token을 이용한 로그인 기능 구현 ✨ 입력값에 따른 유효성 검사 ✨ 로그인 성공시 페이지 이동 구현

✅ 메인 페이지

✨ 메인페이지 레이아웃 구현 ✨ 메인페이지 캐러셀 슬라이더 기능 ✨ 메인페이지 API 통신을 이용한 세일, 신상품 품목 렌더링

✅ 상품 리스트 페이지

🌈 API 통신을 통해 각 카테고리 몇 상품 리스트 구현 🌈 query string을 이용한 필터기능 구현(인기도순, 낮은가격, 높은 가격, 최신 등록) 🌈 동적 class 를 이용한 4가지 레이아웃 기능 (리스트뷰, 이미지뷰, 큰 이미지뷰, 갤러리뷰) 🌈 offset을 이용한 페이지네이션 기능 🌈 페이지 사이즈 관련 기능(10개씩 보기, 20개씩 보기, 30개씩 보기) 🌈 동적라우팅 이용한 상세페이지 이동 구현 🌈 access token 을 이용한 사용자 인증 및 찜하기 기능 구현 (로그인 유저만 찜하기 가능 및 유저에 따라 다른 찜하기 상태를 보여줌) 🌈 간략보기 버튼 클릭 시 모달창으로 상품 상세 미리보기 구현

✅ 상품 상세 페이지

🌈 API 통신을 통해 해당하는 상품의 상세 페이지 구현 🌈 상품의 수량 조절 기능 구현

✅ 하단 footer

✨ 레이아웃 구현

✅ 상단 Navbar

🌈 동적라우팅 이용한 카테고리에 맞는 리스트 페이지로 이동 구현 🌈 검색 기능 구현(query string 및 동적 라우팅 이용) 🌈 access token을 활용한 로그아웃 기능 구현

결과 화면

1. 회원가입

validation check를 통해서 사용자가 올바른 값을 입력할 수 있도록 유도했다. 여러가지 값을 입력 받고 이를 검증해야 되기 때문에 까다로웠지만 보배님께서 백엔드에만 검증을 맡기지 않고 프론트에서도 최대한 검증을 할 수 있도록 구현했다.

2. 로그인

회원가입과 마찬가지로 validation check를 통해서 사용자의 입력값이 유효한 경우에만 로그인 버튼을 누를 수 있도록 했다. 마찬가지로 백엔드와 프론트엔드 양쪽에서 2중으로 유효성 검사가 진행되도록 했다.

3. 메인 상단

백엔드 API를 통해서 데이터를 전달받아 이를 메인 상단에 보여줄 수 있도록 했다. background-image를 이용해서 이미지가 변경되면서 슬라이드 될 수 있도록 했고 애니메이션 효과를 통해서 단조로움을 벗어날 수 있었다.

4. 메인 상품 탭

4개의 상품을 묶어서 보여줄 수 있도록 했다. 이 때, 신상품과 세일 상품이라는 카테고리의 정보를 랜덤하게 받아와서 사용자가 접속할 때마다 다른 상품을 보여줄 수 있도록 구현했다.

5. 상품 리스트 - 필터

state 를 이용해서 각 필터에 해당하는 버튼을 누를 때 query string 을 통해서 새로운 정보를 받아올 수 있도록 했다. 백엔드에서 query string 을 이용한 API를 빠르게 만들어줘서 어렵지 않게 구현할 수 있었다. 모든 데이터를 받아서 프론트에서 정렬할 수 있겠다는 생각이 들기도 했지만 여러 데이터를 다루는 것이 커머스 사이트의 특징이라는 생각에 query string 을 이용하는 것이 낫다는 판단을 했다.

6. 상품 리스트 - 4가지 버전 레이아웃

className 을 동적으로 변화시켜서 4개의 버전의 레이아웃을 구현했다. 실제 사이트의 경우에는 query string 을 이용하는 것처럼 보였으나 여러번의 요청을 보내고 싶지 않았기 때문에 동적 className 을 사용하였다.

7. 상품 리스트 - 페이지네이션

다수의 상품을 한 번에 받아오는 경우에 시간이 많이 소요될 수 있기 때문에 이를 제어하기 위해서 페이지네이션 기능을 구현했다. offset 를 상품 수와 현재 페이지를 통해서 계산한 뒤에 전달하여 해당하는 상품만 통신해서 받아올 수 있도록 했다.

또, 한번에 보고자 하는 상품의 수량을 조절할 수 있도록 했다.

8. 상품리스트 - 찜하기 & 간략보기

로그인 시에 발급 받았던 token 을 이용해서 사용자에 맞는 찜하기 상황을 보여줄 수 있도록 했다. 또, 로그인한 유저의 경우에만 찜하기 기능을 사용할 수 있도록 했다. 이는 바로 반영되어서 찜하기가 눌린 상품의 경우 인기도 순으로 정렬할 때 더 높은 우선도를 갖게 된다.

상품을 누를 경우에 상세페이지로 이동하게 되는데, 리스트를 계속 보면서 상품의 정보를 자세히 보고 싶은 유저를 위해서 간략보기 기능을 구현했다.

9. 네비바 - 검색 기능

네비바에서 각 카테고리를 누르면 해당하는 상품 리스트로 이동하게 구현했고, 검색어를 입력한 경우에는 해당하는 상품들을 보여줄 수 있도록 했다. query string 과 동적라우팅을 이용해야 했는데 처음에는 다소 헤맸지만 여러 시도 끝에 성공할 수 있었다.

10. 상세페이지

동적라우팅을 통해서 상품 리스트 페이지에서 원하는 상품을 클릭한 경우에 이동할 수 있도록 했다. 옵션을 선택한 경우에만 상품의 수량을 조정할 수 있도록 했다.

✨ Project Review

좋았던 점

소통을 통한 구현 과정

우리 팀은 백엔드와 프론트엔드 사이에서의 의사소통에 큰 문제가 없었다고 생각한다. 코드를 작성하면서 미리 미치 key 값들을 맞춰보기 위해서 생각했고 백엔드에서 얻은 구조를 바탕으로 Mock data 를 만들어 사용했기 때문에 수정사항이 많이 생기지 않았다.

또한, 프론트엔드와 백엔드 사이에서 각 기능들을 구현하는 경우에 어떤 방식으로 동작하는 것이 옳을 지에 대해서 이야기 할 수 있는 시간들이 많았는데 한 쪽의 주장만 일방적으로 하는 것이 아니라 서로 납득할 수 있는 부분으로 협의하면서 만족스러운 결과를 낼 수 있었다.

특히 찜하기 기능의 경우에는 서로 의견을 많이 나눌 수 있었고 인증과 인가를 통해서 유저에 따른 다른 화면을 그리도록 할 수 있었다.

목표는 작게, 구현은 확실하게

PM이었던 동규님의 말처럼 우리 팀은 많은 목표를 설정하지 않았다. 구현할 수 있는 최소한을 설정하였고 이 부분은 최대한 확실하게 구현할 수 있도록 했다. 그렇기 때문에 프로젝트 기간동안 팀원들이 아프기도 하고 백신으로 인해서 생겼던 어려움도 있었지만 차근차근 목표들을 이뤄나갈 수 있었다.

또, 각자 맡은 페이지의 경우에는 사소해 보일지라도 최대한의 기능들을 구현하기 위해서 노력했고 그 마음만큼 괜찮은 결과를 냈다고 생각한다.

자꾸만 솟아나는 욕심과 부족한 내 실력 사이에서 힘들기도 했던 프로젝트 기간이었지만 같은 방향을 바라보고 함께하는 팀원들이 있었기에 힘내서 진행할 수 있었다.

아쉬운 점

코드 리팩토링의 부족...

생각보다 내 속도는 느렸고 맡은 기능들을 구현하는데 꽤 긴 시간이 걸리게 됐다. 그러다보니 나중에는 코드의 질에 대해서 깊이 고민할 수 있는 시간이 부족했다. 빠르게 구현을 마무리하고 팀원들간에 코드 리뷰를 통해서 리팩토링을 할 수 있는 시간을 가질 수 있었다면 좋았을텐데 그러지 못한 점이 아쉽다. 그래도, 멘토님들의 지속적인 피드백을 통해서 부족했던 부분들을 채워나갈 수 있었던 점은 좋았다.

긴밀한 소통의 필요성

무난하게 소통이 진행되었다고 생각하기는 하지만, 서로 간의 긴밀한 소통의 경우에는 조금 부족했다는 생각이 든다. 특히 프론트엔드의 경우에는 각자 맡은 페이지를 최대한 잘 그려내기 위해서 시간이 많이 들었는데 그러다보니 서로의 진행사항이나 어려운 점에 대해서 빠르게 공유하는 것이 어려웠다. 주말에 만나서 함께 하거나 서로의 코드를 보고 개선하는 것을 돕기도 했지만 기술적인 것을 떠나 심적으로 더 공유하고 나눌 수 있었다면 좋았겠다는 생각이 든다.

특히 팀원분들이 아픈 상황에서도 맡은 역할에 대한 부담감을 가지고 있던 상황을 생각하면 마음 편히 이야기를 나눌 수 있도록 하는 역할을 하지 못했던 것 같아 미안한 마음이 든다. 마음 깊이 의지할 수 있는 동료 개발자는 어떤 사람인지에 대해서 생각해보는 계기가 되었다.

프로젝트 후기

처음으로 진행했던 1차 프로젝트. 시작 전에는 정말 걱정이 많았는데 좋은 분들을 만나서 즐겁게 진행할 수 있었다. 진행하는 2주 동안은 잘하고 있는걸까? 이게 하나의 사이트가 될 수 있을까? 감이 오지 않았는데 서로의 결과물들이 합쳐져서 하나가 되었을 때는 정말 기분이 좋았다.

특히 여러 번, 서버를 열어달라고 이야기 하기도 하고 회의 때마다 해야할 것들에 대해서 중요하게 이야기 했던 것 같아서 미안한 마음이 큰데, 싫은 내색 없이 오히려 더 열심히 함께 해줬던 DOT 프렌즈 팀원들에게 정말 감사하다.

PM으로서 열정적으로 팀을 이끌고 격려해주었던 동규(보스)님, 즐거움 뿐만 아니라 든든하게 백엔드로서 지원해 줬던 우주(문)님, 많은 사색으로 좋은 API를 만들어줬던 동준(브라운)님, 항상 웃으며 성실하게 맡은 역할을 다 했던 은정(에드워드)님, 아이디어 뱅크에, 아파서 고생하기도 했지만 주말에도 만나 말한 것들은 다 해낸 보배(샐리)님까지. 각자의 공간에서 잘 지내자며 정했던 DOT FRIENDS 였지만 하나의 팀으로 좋았던 2주였고 단단했던 프로젝트였다.

JavaScript를 공부하면서 여러가지 문법에 대해서 공부를 했지만 if문 에서의 구문과 표현식의 차이에 대해서는 진지하게 고민해 본 적이 거의 없었다. 이번 프로젝트를 하면서 이에 대해서 크게 느낄 수 있었는데, 이에 대해 정리해보자.

if문과 삼항연산자

본격적으로 프로젝트를 하면서 받았던 많은 피드백 중에 하나가 if, else 문을 사용했던 내용을 삼항연산자로 바꿔보라는 것이었다. 얼핏 보기에도 삼항연산자를 사용했을 경우에 식이 간결해지기 때문에 가독성에 좋아보이기는 했지만 구체적인 이유에 대해서는 고민이 없이 사용을 했었다.

if(a > 0){
  console.log("wow");
} else {
  console.log("no!!");
}

위의 식은 삼항 연산자를 사용하면 아래처럼 간단해 진다.

a > 0 ? console.log("wow") : console.log("no!!");

무엇인가 간단해지고 좋은건 알겠는데 정확히 좋은 이유는 뭘까?

구문과 표현식의 차이

간단하게 설명하자면 구문의 경우에는 변수에 할당할 수가 없다. JavaScript 를 사용하는 사람이라면 아래처럼 사용하는 경우를 보지 못했을 것이다.

const print = if(a>0){
                return "wow";
              } else{
                return "no!!";
              };

당연히 위와 같은 방식으로 사용하는 경우는 없다. 다만 아래는 가능하다.

const print = a>0 ? "wow" : "no!!";

이런 차이로 인해서 표현식의 경우에는 리액트의 JSX 안에서도 사용이 가능하며 변수에 할당하여 필요한 경우에도 자유롭게 사용할 수 있다.

사용 예시

1차 프로젝트를 진행하면서 상세페이지 에서 수량을 더하고 빼는 기능을 만들어야하는 경우가 있었다. 이를 더하는 함수와 빼는 함수 두개로 만들고 싶지 않아서 하나의 함수로 만들고 싶었는데 처음에는 아래와 같이 작성했다.

updateCount = (e, action) => {
    switch (action) {
      case 'add':
        this.setState({ count: this.state.count + 1 });
        break;
      case 'substract':
        const count = this.state.count - 1;
        this.setState({ count: count > 1 ? count : 1 });
        break;
      default:
        break;
    }
  };

코드를 살펴보면 "add" 와 "substract" 라는 action 을 받아서 더하거나 빼는 함수임을 알 수 있다. 두 개의 함수를 만들 것을 하나로 만들었기 때문에 작은 목표는 달성했지만 표현식의 특성을 이용하면 이렇게 바꿀 수 있었다.

updateCount = (e, action) => {
  const count =
    action === 'add' ? this.state.count + 1 : this.state.count - 1;
  this.setState({ count: count > 1 ? count : 1 });
  };

count 라는 변수에 삼항연산자의 결과를 바로 할당하고 이를 setState() 할 수 있도록 했다.

비록 복잡한 기능을 하는 함수도 아니고 간단한 이야기이지만 이런 작은 것들이 모여서 큰 것들을 만들 수 있다고 생각한다. 앞으로도 불필요한 코드를 줄여나가는 일에는 집중해 볼 예정이다.

계산된 속성명이란 ES6 부터 지원되는 기능으로, 객체의 속성명이 최초에 결정되는 것이 아니라 동적으로 결정되는 것을 말한다. 이를 사용하는 경우에는 dot notation이 아니라 [] 을 사용한다.

사용하는 이유?

계산된 속성명은 주로 비슷한 동작을 줄일 때 사용할 수 있다. 1차 프로젝트를 진행하면서 상품 리스트 페이지를 담당하게 되었는데 필터 기능, 페이지 사이즈 관련 기능, 페이지네이션 기능 등을 이용하려다 보니 비슷한 동작을 하는 여러 개의 함수가 만들어지게 됐다.

// 비슷한 3개의 함수
getViewType = type => {
    this.setState({ viewType: type });
  };

getFilterType = type => {
    this.setState({ filter: type });
  };

getCurrentPage = num => {
    this.setState({ page: Number(num) });

기능에는 문제가 없었으나 계산된 속성명을 이용하면 이를 하나로 줄일 수 있어보였다. 3개의 함수 모두 단순하게 setState() 만을 목적으로 하고 있기 때문이었다.

사용 예시

 getPageOption = (value, setTarget) => {
    this.setState({ [setTarget]: value });
  };

비슷한 동작을 하는 3개의 함수는 계산된 속성명을 통해 하나의 함수로 줄일 수 있었다. 위를 보면 setTarget 이라는 매개변수를 통해서 setState 안에서 [setTarget] 이 동적으로 계산되면서 상황에 맞게 들어가고 있음을 알 수 있다. 여기서 []을 사용하지 않으면 setTarget 에 들어오는 인자가 아닌 setTarget 이라는 이름을 가진 프로퍼티에 value 가 할당되기 때문에 원하는 대로 동작하지 않는다.

개인적으로 프로젝트를 하면서 마음에 들었던 코드 중에 하나이다. 항상 느끼는 바이지만 동일한 동작을 하는 코드를 줄여나가고 가독성을 늘릴 수 있을 때 짜릿함이 느껴진다. ✨

백엔드에서 보통 가지고 있는 데이터의 경우에는 그 양이 많은 경우가 대부분이다. 이런 데이터를 전부 가져와서 보여준다면 시간이 오래 걸리게 된다. 그렇기 때문에 한 번에 받을 데이터를 설정하여야 하는데, 이때 필요한 것이 바로 Pagination 이다.

limit & offset

백엔드 입장에서는 보통 프론트엔드로부터 보내진 limit 을 통해서 몇 개의 데이터를 보내줄지 결정하게 되는데 이때 offset 에 대한 정보를 추가로 보내서 보내줄 데이터의 시작 지점을 결정할 수 있다.

만약 offset 이 0이고 limit 이 10이라면 백엔드에서는 인덱스가 0부터 9인 상품을 보내게 될 것 이다. 이때 다음 상품을 받기 위해서 프론트엔드에서는 offset을 새롭게 수정하여 보내줘야 한다.

offset 구하기

offset 을 구하는 방법이야 다양하게 있겠지만 간단한 방법을 하나 제시하고자 한다. 그것은 바로 현재 보여주고 있는 페이지의 숫자와 한 페이지에서 보여주는 상품의 갯수를 이용하는 방법이다.

즉, offset = (page-1) * limit 이다. 만약 2페이지를 볼 예정이고 10개의 상품을 보여줄 예정이라면 전달해 줄 offset 은 10이 될 것 이다. 이 요청에 따라 백엔드에서는 10번 인덱스부터 19번 인덱스까지 10개의 상품을 보낼 것이다.

여기서 제시한 페이지네이션이 정답은 아니다. 통신 환경에 따라서 여러 가지 방법이 있기 때문에 상황에 맞는 방법을 택해서 사용하면 된다. 페이지네이션의 경우에 자주 사용되기 때문에 대략적인 흐름을 이해하는 것이 좋다고 생각한다.

처음에 공부를 할 때 HTML / CSS 로만 동적인 효과를 만드는 것은 뭔가 꼼수를 쓰는 것 같은 기분이 들었던 적이 있다. 하지만, 공부를 하면서 느낀 것은 수많은 동적 효과들을 JavaScript 를 통해서만 구현하는 것보다 간단하게 HTML/CSS 를 통해서 구현하게 되면 좋다는 것을 알게 됐다. 유용하게 사용될 동적 클래스에 대해서 알아보자.

동적 클래스

동적 클래스?

동적인 클래스를 이용한다는 것은 조건에 따라서 HTML 태그의 class 를 변경하여 동적인 변화를 준다는 뜻이다.

위의 예시처럼 class 의 변화를 통해서 동적인 효과가 부여되었다.

예시

 <div className="controller">
          {BTN_TYPE.map((item, idx) => (
            <button
              className={`${item.type} ${
                item.type === viewType ? 'active' : ''
              }`}
              onClick={this.getViewType}
              id={item.type}
              key={idx}
            >
              <i className={item.icon} />
            </button>
          ))}
        </div>

위의 예시를 보자. 위는 4가지 레이아웃 모드를 제공하는 버튼들을 구현하기 위해서 Array.map() 을 이용한 상황이다. 위에서 각 버튼에 부여되는 className 을 보면 조건에 따라서 각 아이템의 타입과 현재 보여질 타입이 같은 경우에 active 라는 클래스를 더해주는 것을 알 수 있다. 이를 통해서 버튼의 모습이 변경되도록 할 수 있다.

버튼을 예시로 들었지만 버튼과 함께 변화되는 각 상품 이미지의 변화 역시 동적인 클래스 네임을 이용해서 구현하고 있다. 이처럼 다양한 상황에서 사용될 수 있기 때문에 기억하고 익숙해지면 좋을 것 같다.

1차 프로젝트를 진행하면서 fetch 를 사용해야하는 일이 많아졌다. 상품 리스트 페이지를 맡게 됐는데 라인프렌즈의 경우에 필터 관련된 기능들이 여러가지가 있어서 이 때 새 요청을 보내 다른 데이터를 받아오기 위해 update 와 관련된 라이프 사이클 메소드가 필요했다.

componentDidUpdate

기본 사용법

componentDidUpdate 의 경우에는 componentDidMount 의 경우와는 다르게 state 나 부모 컴포넌트로부터 받은 props 에 변동사항이 있는 경우에 사용할 수 있는 요소이다.

사용법은 아래와 같다.

componentDidUpdate = (prevProps, prevState) => {
    fetch('data/ProductData.json')
      .then(result => result.json())
      .then(list => this.setState({ list, totalProducts: list.length }));
  };

만약 위와 같은 상태로 사용을 하게 되면 어마어마한 일이 발생하게 된다. fetch 안에서 setState() 를 하고 있기 때문에 state 에 계속 변경이 생기게 되고 무수한 요청을 보내게 된다. 그렇기 때문에 이를 막기 위해서 componentDidUpdate 를 사용하는 경우에는 조건을 제시해줘야 한다.

조건

componentDidUpdate = (prevProps, prevState) => {
    if (this.state.filter !== prevState.filter) {
      this.getData();
    }
  };

위의 예시를 보면 현재 state 에 있는 filter 의 값과 이전 state 의 filter 의 값이 같지 않은 경우에만 componentDidUpdate가 발생할 수 있도록 했다. 이렇게 작성을 하면 원하는 조건에서만 데이터를 요청할 수 있다.

라이프 사이클의 경우에 다룰 내용이 많이 있기 때문에, 나중에 한 번 제대로 정리를 해볼 생각이다. 우리가 원하는 시점에서 원하는 동작을 할 수 있는 라이프 사이클 메소드에 대해서 차근 차근 친해져보자.

React 를 통해서 인스타그램 클론 코딩을 진행하면서 여러 일들이 있었지만 그 중에서 어려웠던 한 가지를 뽑자면 바로 Lifecycle 에 관련된 일이다. 정확하게 Lifecycle에 대해서 모르는 상태로 관련 메소드를 사용하다 보니 여러 에러를 겪을 수 밖에 없었다.

React가 화면을 그리는 방식

React에서 특히 클래스형 컴포넌트를 사용하는 경우에 화면이 그려지는 방식은 아래와 같다.

1. 생성자 함수인 constructor() 가 호출된다.
2. 화면을 렌더링 하는 render() 메소드가 호출된다.
3. componentDidMount() 가 호출된다.

만약 내가 그리고자 하는(특히, Array.map() 을 이용해서 그릴 예정인) 데이터가 componentDidMount() 를 통해서 불러와야 하는 경우에는 아래와 같은 에러를 겪게 될 것이다.

나는 위의 상황을 정확히 알지 못했기 때문에 어째서 Array.map() 가 작동할 수 없는지에 대해서 많은 고민을 했다.

componentWillMount

공식문서를 통해서 화면을 렌더링 할때 호출되는 순서에 따른 에러임을 알게 된 나는 componentWillMount() 를 사용했다. render() 보다 빠르게 호출되기를 원했기 때문이었다. 동작은 잘 되었지만 이는 옳은 방법이 아니었다.

리액트 공식문서에 따르면 componentWillMount 의 경우에 이름이 변경되기도 했으며, 추후 버전에서는 삭제될 예정이라고 한다. 이제는 getDerivedStateFromProps() 라는 메소드를 통해서 render() 전에 호출되도록 할 수 있지만 이는 매우 특별한 경우에만 사용하라고 되어있다.

constructor()

그렇다면, 대안이 무엇일까. 이 역시 문서에 따르면 constructor() 또는 componentDidMount() 를 통해서 해결하는 방법을 권장하고 있다. 여기서 constructor() 의 경우에는 생성자 함수이기 때문에 되도록 초기화와 관련된 내용만 처리하는 것을 권장하고 싶다.

조건부 렌더링

마지막으로 우리에게는 결국 되돌아와서 componentDidMount() 라는 선택지가 주어졌다. 이를 쓰기 위해서 우리가 해줄 수 있는 것이 바로 조건부 렌더링 이다.

웹페이지를 구성하다보면 특정 상황이나 조건에 따라서 화면을 렌더링해야하는 경우가 생겨날 수 밖에 없는데 이때 사용하는 것이 조건부 렌더링이다.

// && 연산자 사용
<ul>
    {comments && comments.map(comment => (
      <Comment
        key={comment.id}
        comment={comment}
        onDelete={this.handleDelete}
        onLike={this.handleLike}
      />
    ))}
</ul>

위의 코드를 보면 comments 가 true 라면 comments.map() 이 실행되도록 하고 있다. 위의 코드를 삼항연산자 를 통해서 작성할 수 있는데 단순히 false 경우에는 동작하지 않도록 하고 싶은 경우라면 && 연산자가 가독성 측면에서 좋다.

위의 코드는 아래처럼 사용할 수도 있다.

// ?. 사용(optional chaining)
<ul>
    {comments?.map(comment => (
      <Comment
        key={comment.id}
        comment={comment}
        onDelete={this.handleDelete}
        onLike={this.handleLike}
      />
    ))}
</ul>

위는 ?.(optional chaining) 을 사용한 방식이다. 프로퍼티에 접근할 때 만약 null 이나 undefined 라면 단락하고 undefined 를 반환하는 방식이다. 남용하는 것은 유지보수에 좋지 않기 때문에 꼭 필요한 경우가 아니라면 지양하자.

첫 React 프로젝트

JavaScript 를 통해서 구현했던 인스타그램을 다시 React 를 통해서 구현하는 프로젝트를 하게 됐다. 기존에 DOM 을 조작해서 넣었던 기능들을 state 와 props 를 이용해서 구현하려다 보니 어려운 점도 많았는데, 돌이켜보면 어째서 React 를 써야하는지 느끼게 된 프로젝트이기도 했다. 초면이었던 React 와 조금은 친해지게 된 위스타그램 에 대해 정리해본다.

제작 기간

2021.08.23 ~ 2021.08.26

사용 기술

- HTML / SASS - JavaScript(ES6 + ) - React

구현 사항

• *Login : 아이디, 패스워드 유효성 검사 로직 *
• *Login : 백엔드 API를 통한 회원가입 & 로그인 구현 *
• *Main : Mock data 통한 피드 및 댓글 구현 *
• *Main : 댓글 추가 & 삭제 구현 *
• *Nav : 검색어 자동완성 기능 구현 *
• *Nav : 프로필 메뉴 토글 기능 구현 *

결과 화면

** 댓글 추가 기능 **

** 댓글 삭제 & 좋아요 기능 **

** 아이디 검색 기능 **

** 프로필 메뉴 토글 기능 **

👀 Project Review

React... 님은 뭘까?

• UI 를 위한 자바스크립트 라이브러리
• 선언적 특징을 가지고 있는 라이브러리
• 재사용성이 가능한 UI 단위 컴포넌트

리액트 관련 세션을 듣고 생각보다 익숙한 모습에 친근하게 느껴졌다. JSX 는 HTML 태그와 모습이 비슷했고 class 가 낯선 것만 빼면 JavaScript 니까 금방 할 수 있을거라 굳게 믿었다.

하지만... 세션 후에 JS 로 구했했던 코드들을 CRA 폴더에 옮기고 화면을 그리자 당황스러움이 느껴졌다. 심지어, 첫 협업으로 같은 폴더를 공유하며 진행해야하다보니 함부로 파일들을 수정할 수 없었는데 이로 인해서 많은 어려움이 있었다.

특히 Nav 부분을 맡아서 진행하다가 나의 허술함을 강력 어필하게 됐다. master 가 아닌 개인 branch 에서 nav 관련 branch 를 생성했다가 작업물이 사라지는 경험을 하기도 하고 여러 번의 수정으로 팀원들에게 반복되는 사과를 하기도 했다.

무엇보다... state 와 props 를 사용해서 기능들을 구현하는 방법은 사고의 방향이 다르게 느껴져서 혼란스러웠다. 하지만, 결국에는 React 가 얼마나 좋은 것인지 알게 되었다.

리액트와 강강수월래! 🤟🏻

API를 통한 통신!

이번 주 세션 중에서 가장 재밌었던 순간을 뽑자면 바로 백엔드와 연결을 해보는 시간이 아니었나 싶다.

// 회원가입 코드
handleSignUp = event => {
    fetch('${baseUrl}/users/sign-up', {
      method: 'POST',
      body: JSON.stringify({
        name: '하루',
        email: this.state.id,
        password: this.state.password,
        phone_number: '010-1111-2222',
        date_of_birth: '2001-01-02',
      }),
    })
      .then(result => result.json())
      .then(result => console.log(result));
  };

프론트엔드의 경우에는 간단한 유효성 검사 정도의 로직만 구현을 했다보니 세션 후에 실습 시간에 바로 코드를 작성해야 했다. 백엔드 페어로 지정되신 우주님에게 key 값과 엔드포인트 에 대해서 물은 후에 바로 코드를 작성했다. 다행스럽게도 금방 400 에러 를 만날 수 있었고 연결은 됐다!! 하며 즐거워했다.

이 과정에서 400 에러 를 자주 봤었는데 이유는 우주님이 작성하신 유효성 검사에 대해서 정확하게 묻지 않고 진행하다보니 생긴 일이었다. 어떤 값들을 입력해야하는지 정확히 의견을 나누고 진행하니 곧 CREATE 라는 메세지를 받을 수 있었다. 나도 모르게 환호성을 질렀던 기억이 난다. 백엔드 최고!

// 로그인 기능
 handleLogin = event => {
    fetch('${baseUrl}/users/login', {
      method: 'POST',
      body: JSON.stringify({
        email: this.state.id,
        password: this.state.password,
      }),
    })
      .then(result => result.json())
      .then(result => {
        result.TOKEN
          ? this.props.history.push('/main-cheoljin')
          : alert('아이디와 비밀번호를 맞게 작성해주세요');
      });
  };

이제 회원가입 한 아이디와 비밀번호를 입력해서 로그인만 시키면 됐다. 엔드 포인트 주소를 바꿔서 입력해 준 후에 body 에 관련된 내용을 담아 보냈더니 진짜로 토큰을 받아볼 수 있었다. 세션으로 듣기만 했던 토큰을 실제로 확인하니 매우 신기했다.

알아먹을 수 없는 토큰이라는 존재가 이렇게 기쁜 존재인지 몰랐다.

이게 컴포넌트?

리액트를 진행하면서 가장 좋았던 점은 한 눈에 보기가 불편했던 코드가 컴포넌트 를 나눌 수록 매우 보기 편해진다는 점이었다.

import React, { Component } from 'react';
import Nav from '../../../components/Nav/Nav';
import Aside from './Aside/Aside';
import Feed from './Feed/Feed';
import './Main.scss';

class MainCheoljin extends Component {
  state = {
    feeds: [],
  };

  render() {
    return (
      <div className="main-cheoljin">
        <Nav />
        <main className="main">
          <div className="main__container">
            <section className="main__feeds">
              {this.state.feeds.map(feed => (
                <Feed key={feed.id} feed={feed} comments={feed.comments} />
              ))}
            </section>
            <Aside />
          </div>
        </main>
      </div>
    );
  }
}

export default MainCheoljin;

기존에는 매우 길어서 원하는 부분을 찾기 위해서 cmd + F 가 필수였는데 지금은 한 눈에 어떤 구조로 만들어져 있는지 볼 수 있게 되었다. 처음에는 기존의 코드를 컴포넌트 로 바꾼다는 점이 어렵게 느껴졌는데 시간이 갈 수록 컴포넌트 들을 더 나누면서 즐거웠다.

하드코딩 멈춰! 🖐🏻

리액트를 배우고 적용하면서 정말 기뻤던 부분은 바로 Array.map() 와 컴포넌트 가 시너지를 만들어 하드코딩을 정말 많이 줄일 수 있게 되었다는 점이었다. 이전에는 피드를 여러개 만들고 싶거나 댓글을 여러개 만들고 싶은 경우에 하나씩 하드코딩하면서 만들어야하는 불편함이 있었다. 이는 코드 역시 쓸데없이 길게 만들어서 가독성도 많이 헤치는 점이었다.

<section className="main__feeds">
 {this.state.feeds.map(feed => (
  <Feed key={feed.id} feed={feed} comments={feed.comments} />
  ))}
</section>

이렇게 컴포넌트 를 만들고 Array.map() 을 이용하면 짧은 코드로도 여러 개의 피드나 댓글을 만들 수 있다. 또한, JavaScript 를 이용해서 DOM 에 이벤트 리스너를 등록하고 함수들을 추가했을 때는 한 개의 피드에서만 정상적으로 동작하는 단점이 있었는데 리액트에서는 컴포넌트 를 통해서 자연스럽게 모든 피드에서 동작하도록 할 수 있었다.

여전히 어렵지만...!!

리액트 의 장점에 푹 빠진 것 같기도 하지만, 여전히 어려운 점은 많다. main 에서 모든 state 를 관리하면서 댓글 추가 & 삭제 기능의 로직이 복잡한 것을 바꿔보기 위해서 feed 에서 자신의 관련된 상태만 받아서 이용할 수 있도록 변경하였는데 이 과정에서 여러 오류를 겪었다. 컴포넌트가 렌더링 되는 과정에 대해서 정확한 이해가 부족하다 보니 생긴 일이었다.

constructor -> render() -> componentDidMount() 순으로 발생한다는 점은 겪어보면서 느낄 수 있던 점이었다. 그 과정에서 Optional Chaining 이나 componentWillMount 등에 대해서도 공부해 볼 수 있었다. 리액트에 대해서 공부할 점이 앞으로도 정말 많을 것 같다는 생각이 든다.

역으로 검색 기능 같은 경우에는 복잡했던 코드가 간단해지기도 했다.

const searchResult = searchValue
      ? searchList.filter(list => list.id.indexOf(searchValue) === 0)
      : PREVIEW_DATA;

만약 사용자가 검색어를 입력한다면 그거에 맞는 데이터만을 전달하여 SearchItem 을 Array.map() 을 통하여 컴포넌트를 그려낼 수 있도록 하고 아니라면 PREVIEW_DATA(이전 검색) 을 보여주도록 했다. 전에 DOM 을 통해서 구현했던 것에 비해 훨씬 간단하게 구현할 수 있어서 놀라웠다.

프로젝트 회고

칭찬하고 싶은 점

우선, 여러가지 일들이 많았던 기간 동안 좌절하지 않고 끈기 있게 리액트에게 말을 걸었던 나에게 칭찬을 해주고 싶다. 쉽지도 않았고 정말 다사다난했지만 새로운 기능에 두려움보다는 호기심으로 다가가기 위해서 노력했다.

무엇보다, 여러 동기분들의 코드를 보면서 문제들이 생겼을 때 해결해보기 위해서 고민했던 시간들이 있어서 좋았다고 생각한다. 다른 사람의 코드를 보는 연습, 문제가 생겼을 때 천천히 디버깅 하는 연습이 되었다고 생각한다. 다소 많은 console.log() 를 찍으며 귀찮게 해드리지는 않았나 싶기는 하지만 같이 문제를 해결해나가는 즐거운 시간이었다고 믿는다.

개선하고 싶은 점

여전히, 코드를 정리해나가고 불필요한 부분을 줄이는 연습은 부족하다고 생각이 든다. 또, 공식문서를 더 많이 읽으면서 항상 최선인지에 대해서 고민하는 연습도 필요하다고 느낀다. 원하는 만큼 기능들을 구현해보기는 했지만 그 과정에서 불필요한 코드가 남기도 하고 다소 부적절한 방법으로 코드를 작성하기도 했다. 이런 부분들은 앞으로 계속 고쳐나가야 하는 점이라고 생각한다.

누가 봐도 읽기 편한 코드, 이해하기 좋은 코드를 작성하도록 노력하자.

✨ 빛나는 동기들

같은 동기분들에게 가끔 질문을 받으면 무언가 도움이 될 수 있는 것 같아 기쁘다. 비슷한 문제를 겪었고 경험했기 때문에 적절한 도움을 드릴 수 있는 경우가 대부분이다. 나 또한, 어려운 문제가 있을 때 질문 하나로 해결이 되는 경우도 정말 많다.

혼자서 진행했다면 어렵고 힘들었을 이 시간들을 함께 걸어나갈 수 있는 동기들이 있어서 정말 좋다. 특히, 나의 열정 정도는 작아보이게 만들만큼 열심히 자신의 길을 걸어나가는 동기님들이 있어서 뒤쳐지지 않기 위해 한 발, 두 발 더 나갈 수 있다.

지금의 내가 옆에서 함께 일하고 싶은 개발자로서 성장하고 있는지는 아직 잘 모르겠다. 하지만, 꼭... 옆에서 함께하고 싶은 개발자가 되도록 더욱 단단하게 걸어보려고 한다. 이 시기를 함께 해주는 24기 동기분들 모두에게 정말 감사하다.

📲 첫 백엔드와의 통신!!

4주차가 되면서 처음으로 백엔드와 통신을 해볼 수 있는 기회가 생겼다. 바로 회원가입 - 로그인 실습이었다. 그 동안 프론트는 화면을 그리고 Mock data 를 이용한 실습정도만 진행을 해봤고 백엔드는 API를 만들기는 했지만 화면으로 볼 기회는 없었는데 드디어 해 볼 수 있었다.

이 과정에서 얻은 깨달음도 있었는데, 그건 key 값의 경우에 많은 소통이 필요하다는 점이었다. 만약, 프론트엔드와 백엔드가 key에 대해 소통이 없다면 무수한 400 에러 를 만나게 될 것이다. 그 다음에 땀을 흘리며 잠시만요!? 를 외치겠지...

👊 리액트

개발자가 되기를 마음 먹으면서, 특히 프론트엔드 개발자가 되기로 결심하면서 자주 들었던 라이브러리가 리액트 였다. 위코드에 가기 전에 경험을 해보고 싶었지만 HTML/CSS 와 JavaScript 에서 공부할 것이 많았고 JavaScript 역시 별로 공부 하지 못한 채로 위코드에 가게 됐다.

그렇기에 개인적인 목표로 프로젝트 전에 최대한 리액트 와 친해지고 싶다는 생각을 했다. 그래서 하나의 기능을 구현하면서도 정말 많은 고민을 해보려고 노력했던 것 같다.

특히, Mock data 실습을 진행하면서 기존의 state 구조가 변경되었고 댓글 추가와 삭제 기능이 망가지게 되었는데 이를 고치기 위해서 정말 여러 방법을 사용해봤다. 우선은 main 페이지에서 state 를 가지고 있었기에 깊이 탐색해 가면서 우리가 변경할 요소를 찾아야했고 이를 구현하기 위해서 고민을 많이 했다. 그 과정에서 props 를 통한 자식 컴포넌트와 부모 컴포넌트 관계에 대해서 많은 깨달음을 얻었던 것 같다.

이상한 비유지만 이해를 쉽게 하기 위해서 나는 기숙사 2층에서 몰래 치킨을 먹기 위해 줄이 달린 바구니를 내리는 비유를 많이 썼다.

1. props 라는 바구니(함수)를 통해서 1층(자식 컴포넌트)에 내려보낸 뒤
2. 먹고자 하는 치킨(필요한 인자) 을 받아서
3. 2층(부모 컴포넌트) 에서 맛있게 먹는(state 변경) 것이다.

또한, 라이프 사이클에 대해서 생각해보는 계기도 있었는데. 상태값의 일부를 피드에서 관리하도록 하기 위해서 constructor(), componentDidMount 등 다양한 방법을 시도했다. 이 때, 어떤 방법이 더 좋은 것인지 고민이 들어서 멘토님들에게 많이 물어보기도 했는데 다양한 의견을 들을 수 있어서 좋았다.

이제는 안녕!

자바스크립트로 인스타그램을 만들 때 검색 기능까지 구현을 했었다. 리액트 로 전환을 하면서 검색 기능이나 프로필 메뉴 토글 등은 미션에 없어서 넘어갈까 했는데 현재님의 이야기를 듣고 개인적으로 진행을 해봤다.

생각했던 것보다 프로필 메뉴 토글 기능의 경우에는 이벤트 버블링 을 어떻게 구현해야 하는지 고민이 들어서 어려움이 있었고 검색 기능 같은 경우에는 오히려 조금 편하게 구현할 수 있었다.

✨ 어떤 시간이었나

🪄 보물창고

위코드에서 한 달을 보내면서 정말 많은 것들을 얻을 수 있었다. 특히, 다른 분들의 코드를 구경하는 것을 좋아해서 많은 동기분들의 코드를 볼 수 있었는데 매번 느끼는 것이지만 배울 것들이 정말 많다.

무엇보다 배움에 대한 태도에 대해서 정말 많이 배울 수 있었다. 단순히 코드를 작성하고 기능을 구현하는 것에서 멈추지 않고 되돌아가 스텝을 되밟아보면서 성취를 더 큰 성취로 만드는 동기분을 보면서 느낀게 많았다.

작은 성취에 머물러 있지는 않은지, 여러가지를 해보고 싶다는 마음으로 중요한 것들을 놓치고 있지는 않은지. 이제 1차 프로젝트를 진행하게 되면서 더욱 바빠지고 많은 성취들을 얻게 될텐데 이 마음을 기억하며 꼭 복기하는 습관을 키워볼려고 한다.

🏃🏻 결국엔 똑같다

한 달을 마무리하면서 연우님이 해주신 말이 있다. 지금 가장 빠른 사람이나 가장 느린 사람이나 나중에는 비슷하다는 말이다. 나는 이 말이 공감됐다. 개발자의 길을 걷기로 한 이상, 그 마음이 진심이었다면. 우리는 앞으로도 많은 어려움을 겪으며 성장할 것이다. 특히, 개발자라고 당당하게 외치기는 살짝 부끄러운 지금의 성취는 앞으로 얻어야할 많은 성취들에 비하면 작다. 한 달간의 우리의 성장이 작아서가 아니라 우리가 앞으로 할 수 있는 것들이 많아서 그렇다.

물론, 가만히 자기 자리에 있는다고 똑같아 지지는 않는다. 그저, 진심이면 된다. 개발자가 되겠다는 마음, 나아가 선한 영향력을 개발로서 이루고 싶다는 마음이면 그렇게 될 것이라고 믿는다. 배워나가는 지금의 우리에게 실력은 다른 것이 아니라 진심이고 열정이다.

🔥 이제 프로젝트!

이제 조금은 두려운 프로젝트를 앞두고 있다. 여전히 작고 작은 내가 민폐를 주지는 않을까 고민도 되고 새로운 사람들과 의사소통하는 일이 걱정되기도 하지만 그 동안의 한 달을 보냈던 것처럼 진심으로 하루 하루를 보내려고 한다.

여러 후기나 멘토님들의 말을 들어보면 프로젝트는 결국 각자의 능력으로 미션들을 쳐나가는 것이 아니라 함께 소통하면서 이뤄나가는 것이라는 생각이 든다. 팀 속에서 어떤 태도로 임할 때 더 큰 시너지를 만들어 낼 수 있을 지 고민해야겠다.

** 한 달이라는 시간이 흐르면서 많은 인풋을 소화하느라 지치기도 하는 시간이었던 것 같아요. 커피 한 잔으로 힘이 난다면, 얼마든지 드리고 싶어요 👏! 이제 시작하는 프로젝트도 함께 화이팅입니다. 💪 **

리액트를 처음 접하면 당황스러운 일이, 바로 state 와 props 이다. 리액트는 선언적 특징을 가지고 있기 때문에 직접 DOM 요소를 조작하지 않고 state 의 변화를 통해서 UI 를 리-렌더링한다. 그렇기 때문에 이전에 명령을 통해서 조작하던 방식과는 사고의 흐름이 다르다고 느껴졌다. 하지만, state와 props 은 알면 알수록 재밌고 흥미로운 요소이다. 이에 대해서 정리해보려고 한다.

state

state 는 컴포넌트가 가지고 있는 상태값을 의미한다. 더 정확히는 UI에 대한 정보를 담고 있는 객체라고 볼 수 있다. state 는 불변값이 아니며 언제든지 사용하고 변경될 수 있다.

class Main extends Component {
  state = {
    feeds: [],
  };

  render() {
    return (
      <main className="main>
        <Nav />
            <section className="main__feeds">
              {this.state.feeds.map(feed => (
                <Feed key={feed.id} feed={feed} comments={feed.comments} />
              ))}
            </section>
            <Aside />
        </main>
    );
  }
}

export default Main;

위의 예시는 메인 페이지의 컴포넌트에서 state 를 가지고 있는 모습이다. 메인 페이지는 state에 feeds 라는 배열을 가지고 있다. 이 배열 안에는 또 각 피드의 정보를 담고 있는 객체들이 들어갈 예정이다. 지금은 생성하면서 초기화만 진행했기 때문에 feeds 에 빈 배열이 들어와 있다.

// mock data 받아오기
componentDidMount = () => {
    fetch('http://localhost:3000/data/CommentDataCJ.json', {
      method: 'GET',
    })
      .then(result => result.json())
      .then(feeds => {
        this.setState({
          feeds,
        });
      });
  };

위의 코드는 componentDidMount() 를 통해서 mock data 를 받아오고 이를 이용해서 setState 를 진행했다. 여기서 setState 를 사용해서 업데이트를 한 점을 보자. state 는 UI에 대한 정보를 가지고 있고 이를 렌더링 하기 위해서 존재한다고 볼 수 있다. 만약, state 의 값을 직접 조작하는 경우에는 state의 변화는 있겠지만 render() 가 호출되지 않아서 리-렌더링이 생겨나지 않는다. 그렇기 때문에 setState() 를 호출하고 이 때, render() 가 호출되기 때문에 정상적으로 UI를 그릴 수 있게 된다.

setState의 비동기성

state 를 사용하면서 겪었던 어려움은 setState() 가 비동기적으로 작동하는 점이었다. state 가 잘 업데이트 되는지 확인하기 위해서 console.log(this.state) 를 사용하는 과정에서 한 박자 느린 반응을 보게 된다거나 전혀 예상하지 못한 흐름으로 동작한다거나 하는 오류들을 겪었다. 특히, ID 와 PASSWORD 를 입력하는 상황에서 한 쪽이 사라지는 경우를 겪기도 했다.

this.setState({
  counter: this.state.counter + this.props.increment,
});

만약 위와 같은 코드를 사용하게 된다면 카운터가 제대로 업데이트 되지 않는 상황을 겪을 수도 있다. 되도록 this.state 와 this.props 을 사용할 때 비동기적으로 업데이트 될 수 있음을 명심하고 사용하는 것이 좋다.

props

state 가 컴포넌트 본인이 가지고 있는 상태값이라면 props 은 부모로부터 받은 속성 객체라고 볼 수 있다. 여기에는 배열, 객체 등이 들어갈 수 있고 메소드도 가능하다. state 는 본인이 가지고 있는 값이기 때문에 얼마든지 변경이 가능하지만 props 는 읽기 전용이기 때문에 자식 컴포넌트에서 수정할 수가 없다.

사용하기

class Comment extends Component {
  handleDelete = e => {
    this.props.onDelete(this.props.reply);
  };

  handleLike = e => {
    this.props.onLike(this.props.reply);
  };

  render() {
    const { userName, comment, isUser, isLike } = this.props.reply;
    return (
      <li className="comment-cheoljin">
        <span>{userName}</span>
        <span>{comment}</span>
        <button
          type="button"
          className="comment__heart"
          onClick={this.handleLike}
        >
          <i className={isLike ? 'fas fa-heart' : 'far fa-heart'} />
        </button>
        <button
          type="button"
          className="comment__delete"
          onClick={this.handleDelete}
        >
          <i
            className={isUser ? 'far fa-trash-alt' : 'far fa-trash-alt none'}
          />
        </button>
      </li>
    );
  }
}

export default Comment;

위의 예시를 보자. props 를 구조분해할당을 통해서 userName, comment, isUser, isLike 로 나눴다. 그 후에 각 필요한 부분에 {} 을 통해 사용했다. 또한, handleDelete 등의 함수를 보면 부모 컴포넌트로부터 전달 받은 props 객체의 메소드인 onDelete를 호출하는 함수 임을 알 수 있다.

이처럼 props 는 부모 컴포넌트와 자식 컴포넌트를 연결해주는 다리의 역할을 한다.

더 설명해보자면 자식 컴포넌트인 Comment 에 있는 <button> 에서 onClick 이벤트가 발생하게 되면 handleDelete 함수가 호출되고 handleDelete 함수는 props로 전달받은 onDelete 함수를 호출한다. 이때 인자로 props 인 reply 를 전달할 수 있다.

위와 같은 방식으로 자식 요소에서 발생한 이벤트를 부모 컴포넌트로 전달해서 state 를 업데이트 할 수 있다.

✨ 마치며

오늘은 state 와 props 에 대해서 간단하게 정리했다. 리액트를 처음 접하게 되는 경우에는 어떻게 이용해야 좋을지 막막한 기분을 느끼는 경우가 많은데 사용하는 방법에 대해서 잘 이해한다면 바닐라 자바스크립트만을 사용하는 경우보다 훨씬 편함을 알 수 있다.

앞으로 평생 함께해야 할 state와 props. 막히는 부분이 있는 경우에는 꼭 리액트 공식 문서에서 답을 찾으며 계속 공부해 볼 예정이다.

복사 & 붙여넣기 ... 복사 & 붙여넣기 ... 이 지겨운 반복행위를 어떻게 하면 줄일 수 있을까. 그리고 백엔드에서 아직 API를 만들지 못했다고 하는데... 화면이 잘 나오는지 어떻게 알 수 있을까? 또 하드코딩인가!? 이런 고민을 해결하기 위해서 좋은 방법이 바로 Mock 데이터와 map 을 이용하는 방법이다. 반복 행위를 어떻게 줄일 수 있을지 알아보자.

💾 상수 데이터

상수 데이터란?

상수 데이터는 변하지 않는 정적인 데이터를 말한다. 그렇기 때문에 백엔드와 API를 통해서 가져오지 않는 정적인 데이터들의 경우 상수데이터를 만들어서 효율적으로 구성할 수 있다.

상수 데이터를 사용하는 이유?

인스타그램 클론코딩을 하면서 불편했던 부분은 스토리 피드, 친구 추천, 피드 등을 만드는 과정에서 하드 코딩을 이용하다보니 엄청나게 긴 코드가 나오게 되는 점이었다. 이는 나중에 원하는 부분을 찾기도 어렵게 만들었을 뿐 아니라 전혀 개발자스럽지 못하다는 느낌이 들었다.(복사 & 붙여넣기의 반복...)

이런 UI 부분을 상수 데이터와 map() 메소드를 이용하면 간단하게 표현할 수 있다. 수정이 필요한 경우에도 상수 데이터만 수정하면 반영이 되므로 유지보수에도 큰 장점이 있다.

상수 데이터를 사용하고 싶은 경우에는 JS 파일을 이용하여 작성하고 이를 import 해서 필요한 곳에서 사용하면 된다. 상수 데이터의 경우에는 구별을 위해서 대문자와 _ 를 사용하는 것을 권장한다.

📲 Mock 데이터

Mock 데이터란?

Mock 데이터는 가짜 데이터를 의미한다. 쉽게 말하면 백엔드 API로부터 데이터를 받아오기 전에 닮은 모습의 가짜 데이터를 말한다.

Mock 데이터를 사용하는 이유

개발을 진행하다 보면 많은 일이 발생하게 된다. 특히, 백엔드의 API가 아직 만들어지지 않은 상황임에도 불구하고 프론트엔드 개발도 계속 진행되어야 하는 경우도 있다.

이때, 데이터 값을 받아올 수 없기 때문에 하드코딩을 진행하여 화면을 구현하고 나중에 데이터를 이용하기 위해 바꿔야 한다면 정말... 답답한 일이 될 것이다.

데이터는 매일 먹는 아침 같은 것이 아니다. 프론트엔드 개발자는 API가 아직 없더라도 데이터를 화면에 예쁘게 보여주는 것이 중요하다. 그렇기 때문에 책임감을 가지고 Mock 데이터를 이용해보는 것이 좋다.

💡 주의할 점!! Mock data 혼자서 만들고 화면으로 구현한다고 모든 문제가 해결되지는 않는다. 만약 백엔드와 소통 없이 Mock data 를 만들고 결국 key 값들이 다르다면 무수한 에러들을 만나게 될 것이다. 꼭 사전에 소통하여 받을 데이터와 같은 key 들을 가질 수 있도록 하자.

🖨 Mock 데이터 활용하기

Mock 데이터 예시

// json 파일
[
  {
    "id": 1,
    "profile": "/images/cheoljinJu/food.jpeg",
    "userName": "CheoljinJu",
    "url": "/images/cheoljinJu/food.jpeg",
    "comments": [
      {
        "id": 1,
        "userName": "현재님",
        "comment": "안녕하세요!",
        "isUser": false
      },
      {
        "id": 2,
        "userName": "동희님",
        "comment": "오히려 좋아",
        "isUser": false
      },
      {
        "id": 3,
        "userName": "영현님",
        "comment": "이 노래 좋아합니다!",
        "isUser": false
      },
      {
        "id": 4,
        "userName": "무현님",
        "comment": "말만 하세요.",
        "isUser": false
      }
    ]
  },
  {
    "id": 2,
    "profile": "/images/cheoljinJu/cat.jpeg",
    "userName": "CatCat",
    "url": "/images/cheoljinJu/cat.jpeg",
    "comments": [
      {
        "id": 1,
        "userName": "승찬님",
        "comment": "반갑습니다!",
        "isUser": false
      },
      {
        "id": 2,
        "userName": "성환님",
        "comment": "감사합니다.",
        "isUser": false
      },
      {
        "id": 3,
        "userName": "세준님",
        "comment": "자전거 타고 싶습니다!",
        "isUser": false
      },
      {
        "id": 4,
        "userName": "연우님",
        "comment": "킥오프 기다리셨죠?",
        "isUser": false
      }
    ]
  }
]

위는 인스타그램 내에서 피드들을 가지고 있는 데이터를 간단하게 작성해본 예시이다. 데이터를 보면 2개의 피드가 있고 그 안에 userName, profile, url 등의 정보와 댓글들의 정보를 가지고 있는 comments 로 구성되어 있음을 알 수 있다.

Array.map() 이용하기

 <section className="main__feeds">
              {this.state.feeds.map(feed => (
                <Feed key={feed.id} feed={feed} comments={feed.comments} />
              ))}
            </section>

우리는 여러 개의 feed 를 map() 을 이용해서 렌더링 할 예정이다. 그렇기 때문에 현재 main 페이지의 state 에서 feeds 를 가져와서 렌더링을 한다. 이때 고유한 key 값을 받을 수 있도록 props 로 전달했다.

componentDidMount = () => {
    fetch('http://localhost:3000/data/CommentDataCJ.json', {
      method: 'GET',
    })
      .then(result => result.json())
      .then(feeds => {
        this.setState({
          feeds,
        });
      });
  };

위의 코드는 우리가 만든 json 데이터를 받아오는 fetch 함수이다. componentDidMount() 를 이용해서 컴포넌트가 화면에 렌더링 된 후에 데이터를 받고 이를 setState() 를 통해서 리렌더링이 일어나도록 했다.

이때, 우리는 데이터를 요청해서 받아만 올 예정이기 때문에 method 로 GET 를 사용했다.

✨ 마치며

이렇게 우리는 fetch 를 이용해서 데이터를 받아오는 방법과 componentDidMount 가 언제 발생하게 되는지, 그리고 Mock 데이터와 map() 을 활용해서 어떻게 반복되는 작업을 줄이고 간결하게 만들 수 있는지 정리했다.

바닐라 JavaScript와 HTML 을 사용해서 인스타그램을 만드는 과정에서 정말 코드가 길어지고 가독성이 나빠졌던 경험을 했는데 이번 내용들을 통해서 이를 많이 개선할 수 있어서 좋은 경험이었다.

Mock 데이터 와 map() 경우에는 정말 많은 활용성을 가지고 있기 때문에 꼭 기억하고 많은 활용을 해볼 예정이다.