큰 규모의 프로젝트를 출시한 뒤, 후일을 위해서 더 늦기 전에 파일 정리 및 문서화를 진행해야했다.

문서화 작업을 하는 중에 기왕 정리하는 거 파일 구조를 이쁘게 트리 구조로 나열하여 코멘트를 달면 나중에 보더라도 이해하기 더 쉬울 것 같았다.

어떻게 해야 간지나는 트리 구조를 만들 수 있을까 방법을 찾다보니 역시나 파일 구조를 트리로 이쁘게 출력해주는 커맨드 툴이 존재했다.

tree 커맨드에 대해서 알아보고 알짜배기 내용만 정리했다.

설치

나는 Mac을 사용한다. 기본적으로 zsh에 내장되어있진 않으니 Homebrew를 이용해서 직접 tree를 설치한다.

brew install tree

사용법

사용법은 참으로 단순하다. 그냥 터미널에다가 tree dirPath 해주면 해당 경로 아래의 모든 파일 및 폴더 구조를 아래와 같이 이쁜 트리로 출력해준다.

tree ./lib/src

./lib/src
├── animation_widgets
├── common_widgets
│   ├── app_bar
│   ├── buttons
│   ├── dialog
│   ├── image_widgets
│   ├── indicators
│   ├── list_items
│   ├── modal
│   └── search_bar
├── constants
├── demo_widgets
├── error

... 생략 ...

옵션

파라미터를 추가하여 다양한 옵션을 설정할 수 있다. -a : 숨김 폴더 및 파일 표시 -d : 디렉토리만 표시

이외에도 다양한 옵션을 함께 활용할 수 있는데, 나는 이정도면 충분해서 더 알아보진 않았다.

더 자세한 정보가 필요하다면 man tree를 통해 확인해보자.

터미널에 출력되는 걸 복붙하는 건 조금 애송이 같으니까 파일을 따로 생성하여 tree 정보를 저장했다.

tree ./lib/src -d > tree.md

결론

어디서 본 듯한 이쁜 디렉토리 구조를 이제 나도 출력할 수 있다!

우리에게 더 익숙한 REST API와 GraphQL의 차이점이 무엇인지 알아보고, Next.js에서 GraphQL을 사용하는 방법에 대해 알아보겠다.

REST API

Representational State Transfer의 약자로 URL로 자원을 표현하고 HTTP 요청을 통해 CRUD를 실행하는 API이다.

GET api/todos/1
PUT api/todos/1

처럼 HTTP 메소드와 URL을 조합해서 여러 요청을 할 수 있다.

하지만 REST API에는 2가지 단점이 있다.

Over Fetching

API 호출 시 필요 이상의 데이터를 가져오는 것이다. API를 요청하면 좋든 싫든 주는 대로 받아야 한다. 따라서, 자신이 클라이언트에 보여줄 것 이상으로 데이터를 많이 받기 마련이다.

Under Fetching

한 번의 API 호출로 원하는 모든 데이터를 가져오지 못하는 것이다. 즉 필요한 모든 데이터를 가져오기 위해서 2번, 3번 이상의 API 호출을 해야 하는 경우이다.

예시로 스터디 목록과 멘토 목록을 API로 불러오게 될 경우
GET api/study, GET api/study/mentor
이런 식으로 구분해서 2번의 API 요청을 보내야 한다.

API 요청 수가 많아지면 로딩 속도가 저하되기 때문에 비경제적이다.

GraphQL

GraphQL은 위의 Over Fetching과 Under Fetching을 해결하기 위해 등장한 specification이다. GraphQL은 하나의 endpoint에 자신이 원하는 만큼만 데이터를 요청하고 받기 때문에 overfetching, underfetching이 없다.

그러면 REST 안 쓰고 다들 GraphQL 쓸텐데 왜 그렇지 만은 않을까?

GraphQL도 단점이 있다.

1. HTTP 캐싱을 활용하기 어렵다
   REST의 경우 endpoint 별로 캐싱을 지정할 수 있는 반면
   GraphQL은 단일 endpoint 이기 때문에 활용하기 어렵다.

2. 에러 핸들링이 어렵다
   여러 데이터를 하나의 endpoint에 묶어 요청하니 당연히 어렵다

3. 요청이 무거워진다
   클라이언트 측에서 보내는 요청의 쿼리가 복잡해지고
   이에 대응하기 위해 백엔드에서는 더욱 정교하게 설계해야 한다.

결론: GraphQL은 경제적이지만 설계와 사용이 복잡해진다.

Next.js에서의 GraphQL

https://beta.pokeapi.co/graphql/console/

위의 링크는 포켓몬 데이터 GraphQL 서버이다.
간단하게 포켓몬의 id, 이름, 기술명을 받아와서 페이지에 뿌려보겠다.

API의 endpoint는 https://beta.pokeapi.co/graphql/v1beta로 하나이고
Explorer에서 원하는 데이터를 선택하고 실행하면 데이터를 확인할 수 있다.

vscode에서 Next 프로젝트를 하나 생성 해준다.

page.tsx에 내용을 싹 날려주고

npm i @apollo/client graphql

import { ApolloClient, InMemoryCache, gql } from "@apollo/client";

const client = new ApolloClient({
  cache: new InMemoryCache(),
  uri: "https://beta.pokeapi.co/graphql/v1beta",
});

interface Pokemon {
  base_experience: number;
  id: number;
  name: string;
  pokemon_v2_pokemonabilities: {
    pokemon_v2_ability: {
      name: string;
    };
  }[];
}

const GET_POKEMONS = gql`
  query GetPokemons($first: Int!) {
    pokemon_v2_pokemon(limit: $first) {
      id
      name
      base_experience
      pokemon_v2_pokemonabilities {
        pokemon_v2_ability {
          name
        }
      }
    }
  }
`;

const getPokemons = async () => {
  const { data } = await client.query({
    query: GET_POKEMONS,
    variables: { first: 10 },
  });
  return data.pokemon_v2_pokemon;
};

export default async function Page() {
  const pokemons = await getPokemons();
  return (
    <div className="grid grid-cols-5 gap-6">
      {pokemons.map((pokemon: Pokemon) => (
        <div key={pokemon.id} className="border border-white w-80 p-6">
          <h2 className="capitalize text-2xl">{pokemon.name}</h2>
          <p>Base Experience: {pokemon.base_experience}</p>
          <p>
            Abilities:{" "}
            {pokemon.pokemon_v2_pokemonabilities
              .map((ability) => ability.pokemon_v2_ability.name)
              .join(" ")}
          </p>
        </div>
      ))}
    </div>
  );
}

위와 같이 작성해주면 'use client' 나 ApolloProvider 등 사용 없이 간편하게 graphql을 가져다 사용할 수 있다.

주의해야 할 점은 interface를 명시해줘야만 객체가 자동 완성 된다.

참고자료

https://graphql.org/
https://yozm.wishket.com/magazine/detail/2113/
https://www.tabnine.com/code/javascript/functions/apollo-client/ApolloClient/query

트위터 로그인 창을 확인해봅시다.

루트 디렉토리 화면을 배경으로 i/flow/login 페이지가 동시에 표시되고 있습니다.

저는 app router 를 학습하기 전까지는 createPortal 을 사용하여 포탈 영역에 로그인 컴포넌트를 띄우는 방식을 사용했었습니다.

const NoLogin =()=>{

    let [loginModal, setLoginModal] = useState<boolean>(false);
    let [signupModal, setsignupModal] = useState<boolean>(false);


    const loginModalHandler = useCallback((sign:boolean)=>{
        setLoginModal(sign);
    }, [])

    const SignupModalHandler = useCallback((sign:boolean)=>{
      setsignupModal(sign);
  }, [])

    return(
       {/* 생략 */}
        <div className="pt-6">
          <Link href='/' as='/i/flow/login' scroll={false}>
            <button className="rounded-2xl border-2 p-2" onClick={()=>{loginModalHandler(true)}}>
              로그인
            </button>
          </Link>
          {loginModal && createPortal(<LoginModal loginModalHandler={()=>{loginModalHandler(false)}}/>, document.body)}
      </div>
    {/* 생략 */}
)

href 경로와 as 경로를 달리해 뒷배경으로 메인 화면을 띄우고 그 위에 로그인 모달을 띄우는 데 성공했습니다. 하지만 이 방식은 loginModal state 를 정의해서 modal 의 상태를 계속 감시해야하는 번거로움이 있습니다.

Next.js app router 를 학습하며, 모달창을 쉽게 구현하도록 해주는 기능이 내재되어있다는 것을 알게되었고, 위의 createPortal 방식을 넥스트의 parallel routes, intercepting routes 를 활용한 모달창 방식으로 바꿔보고자 하였습니다.

parallel routes

하나의 레이아웃에서 여러 페이지를 동시에 보여줄 수 있는 기능입니다. slots(@folderName)에 의해 생성이 되며, 이렇게 생성된 slot 속 페이지는 slot과 같은 레벨의 레이아웃에 props 로 전달됩니다. (이 때, slot 폴더는 url 에 영향을 주지 않고 무시됩니다.)

넥스트 앱라우터 공식 문서를 참고하며 parallel routes 에 대해 자세히 알아봅시다.

@analytics 와 @team 이라는 slot 이 생성되었습니다. 이들은 모두 같은 레벨의 레이아웃에 props 로 다음과 같이 전달되어 렌더링됩니다.

export default function Layout({
  children,
  team,
  analytics,
}: {
  children: React.ReactNode
  analytics: React.ReactNode
  team: React.ReactNode
}) {
  return (
    <>
      {children}
      {team}
      {analytics}
    </>
  )
}

자 이제 다시 트위터로 돌아가겠습니다. app router 의 파일 컨벤션에 따라서 app 디렉토리에 다음과 같은 폴더 구조를 생성했습니다.

폴더구조를 잘 살펴봅시다. 같은 레이아웃을 공유해야한다는 것, 그것에 따라 폴더 구조를 정렬해야한다는 것을 이해해야 합니다.

@modal 은 props 의 modal로 전달이 되었고, 그 외 요소들은 children로 전달이 되었습니다. 그 후 매칭되는 라우트에 네비게이션할 때 해당 라우팅의 컴포넌트가 렌더링됩니다.

slot 을 따라 레이아웃을 다음과 같이 구성했습니다.

import { ReactNode } from "react"

export default function Layout({children, modal}:{children: ReactNode, modal:ReactNode}){
    return(
        <div>
            {children}
            {modal}
        </div>
    )
}

이제 baseURL/i/flow/login 으로 접속 시 children 부분에는 (beforeLogin)/i/flow/login 이, modal 부분에는 (beforeLogin)/@modal/i/flow/login 이 매핑됩니다.

그렇다면 baseURL/ 로 접속한다면?

children 부분에는 page.tsx 가 매핑되고, modal 부분에는 default.tsx 가 매핑됩니다. (@modal/page.tsx 부재를 default.tsx 가 대체)

default.tsx → parallel route 의 default page. parallel route 가 이용되지 않을 때 이 페이지를 디폴트값으로 띄워줍니다. 즉, 라우팅이 unmatched 할 때 이 페이지를 렌더링합니다. (따라서 위와 같은 상황에 default.tsx 페이지가 없다면 에러가 발생하겠지요.)

하지만 우리가 원하는 것은 i/flow/login/page.tsx 가 동시에 렌더링 되는 것이 아닙니다.. 우리가 원하는 것은 main page(라우팅 주소가 다름)가 뒷배경으로 렌더링 되는 것! 페이지를 동시에 띄우는 것까지 했으니, 주소가 다른 페이지를 렌더링하는 작업을 해보도록 하겠습니다.

Intercepting routes

intercepting routes 는 현재 페이지 컨텍스트를 유지한 채로 새로운 라우트를 렌더링합니다. 따라서 주소가 다른 페이지들을 동시에 렌더링 하고자 할 때 유용합니다.

원하는 화면을 구성하기 위해 layout props 로 children 을 page.tsx 로, modal 을 @modal/i/flow/login/page.tsx 로 전달해봅시다.

interception routes 는 (..) 와 같은 컨벤션으로 정의됩니다.

• (.) 동일한 라우팅 레벨 세그먼트에 매칭

• (..) 부모 라우팅 레벨 세그먼트에 매칭

• (..)(..) 2단계 윗 레벨

• (…) app 디렉토리 루트 요소에 매칭

💡 주의할 것은, 기준이 브라우저 주소라는 것입니다! (라우트 세그먼트 기준)

구조를 위와 같이 바꿔 intercepting routes 를 사용해보았습니다.

다시 구조를 살펴보면, @modal 은 라우팅에 영향을 미치지 않는 slot이지, 라우트 세그먼트가 아닙니다. 그렇기 때문에 @modal 요소 컨텍스트는 유지한 채 (브라우저 주소 상)같은 레벨의 i 요소의 라우팅을 인터셉트할 수 있습니다. ((..)i 로 폴더 이름을 바꾸는 실수를 저지르면 안됩니다.)

이제 layout.tsx 에 children prop 에 page.tsx 가 렌더링되고, modal prop에 i/flow/login 으로 인터셉트한 기존 모달 부분이 렌더링되어 원하던 결과를 얻을 수 있게 됩니다.

(localhost:3000/i/flow/login 화면)

이렇게 모달을 만들면 좋은 점은 다음과 같습니다. (공식문서 참조)

• 뒤로가기/앞으로 가기로 모달을 열고 닫을 수 있음

• URL 통해 모달 내용 공유 가능

• 페이지 새로고침 시 모달이 닫히는 대신 컨텍스트가 유지됨

즉, 페이지를 모달로 띄우기가 가능해 모달 자체가 url 로 관리될 수 있다는 것입니다. createPortal 보다 방법이 직관적이고 간단해서 좋은 것 같습니다.

번외..

왜 인터셉트 후, page.tsx가 children 으로, @modal/i/flow/login/page.tsx 가 modal 로 렌더링되는가?

저는 위 사항이 이해가 가지 않았습니다. parallel routes 는 매칭되는 라우팅에 해당하는 여러 페이지를 동시에 보여준다고 이해했는데, 둘은 매칭되는 라우팅 주소가 다른데 어떻게 동시에 렌더링이 되는 것일까요.

공식문서에 의하면 기본적으로 슬롯에서 렌더링되는 컨텐츠는 현재 url 과 매치됩니다. 그런데 매치되지 않는 슬롯이 있는 경우는 다음과 같이 페이지를 렌더링한다고 합니다.

위는 라우팅이 통일되지 않았습니다. 여기서 /settings 로 이동하는 상황을 가정해보면, @analytics 는 어떤 페이지를 보내줘야할까요?

Softe navigation: 변화된 segments들의 캐시 사용

Hard Navigation: 세그먼트 리렌더링, 데이터 refetch

(출처: https://velog.io/@glassfrog8256/번역-Next.js13-App-Router-Routing-Parallel-Routes)

기본적으로 브라우저는 하드 네비게이션으로 동작하지만, 넥스트 앱라우터는 소프트 네비게이션을 제공합니다. 위에서 제가 느꼈던 의문은 기존 하드 네비게이션 방식이 아닌 소프트 네비게이션 방식으로 페이지 이동이 이루어졌기 때문인 것 같습니다. 아직 정확히 넥스트에서 어떤 기준으로 soft navigation 을 사용하고, hard navigation 을 사용하는지는 모르겠습니다. 추후에 관련 내용을 추가해보고자 합니다.

오류 / 번외 관련 내용은 댓글로 알려주시면 감사하겠습니다.

참고 자료:

https://rocketengine.tistory.com/entry/NextJS-13-Routing-Intercepting-Routes라우트-가로채기

https://nextjs.org/docs/app/building-your-application/routing/parallel-routes

https://nextjs.org/docs/app/building-your-application/routing/intercepting-routes

트리는 노드들이 나무 가지처럼 연결된 비선형 계층적 자료구조이다. 하위 트리가 존재하고, 그 노드에 또 하위 트리가 존재하는 자료구조 이다. 트리의 맨 위에 있는 루트 노드가 존재한다. 우리가 알아볼 트리는 이진 트리이다. 이진 트리는 자식 노드(부모로부터 아래로 이어진 노드)가 2개 이하인 구조를 말한다. 트리의 사용 사례로는 다음과 같다

• 계층 적 데이터 저장(파일,폴더)

• 효율적인 검색 속도

• 힙

• 데이터 베이스의 인덱싱

트리에 관한 용어

• degree - 각 노드가 가진 자식 노드(가지)의 수

• root node(루트 노드) - 맨 위의 노드, 부모가 없다

• leaf node(단말 노드) - 자식이 없는 노드

• internal node(내부 노드) - leaf node가 아닌 노드

• edge - 노드를 연결하는 선

• depth - 루트에서 어떤 노드에 도달하기 위해 거쳐야 하는 edge의 수

• level - 같은 깊이를 가진 노드의 집합, 맨 위부터 레벨 1, 2, 3 순으로 간다.

• height - 루트 노드에서 가장 깊숙이 있는 노드의 깊이

이진 트리의 종류

• 정 이진트리(Strict Binary Tree)

  오직 0 또는 2의 degree의 노드만 존재한다. 즉 자식이 무조건 두 개 또는 한 개이다.

• 포화 이진트리(Perfect Binary Tree)

  모든 노드가 2개의 자식을 가지고 leaf 노드가 모두 같은 level이다.

• 완전 이진트리(Complete Binary Tree)

  마지막 level을 제외하고 모든 노드가 채워져 있어야 한다. 마지막 레벨의 노드는 다 채워져 있을 수도 있고 아닐 수도 있다. 또한 노드는 왼쪽에서 오른 쪽으로 빈 공간 없이 채워져 있어야 한다.

이진 트리의 특징

• height 당 최대/최소 노드

  • 최대 - n = 2^(h+1) -1

  • 최소 - n = h + 1

• strict m-array(최대 dgree가 2인) tree 에서 height 당 최대/최소 노드

  • 최대 - (m^(h+1) - 1) / (m - 1)

  • 최소 - m*h + 1

  • 이진트리는 2-array tree다.

이진 트리의 표현

• array

  하나의 배열에 노드를 순서대로 입력하는 것이다. 일반적으로 맨 위 level의 노드부터 해서 왼쪽에서 오른쪽 순서대로 입력한다.

  

  각 노드의 인덱스에 대한 규칙은 다음과 같다.

• 연결 리스트 활용

  각 노드를 연결 리스트의 노드로 보는 것이다. 각 노드는 데이터와 왼쪽 노드를 향한 포인터, 오른쪽 노드를 향한 포인터로 이루어져 있다.

  

  훨씬 직관적이기에 연결 리스트 형태의 이진 트리 활용을 선호한다.

이진 트리 순회(traversing) 방식

• preorder

  A->B->D->H->I->E->J->K->C->F->G

  부모 노드, 왼쪽 노드, 오른쪽 노드 순으로 순회함

• postorder

  H->I->D->J->K->E->B->F->G->C->A

  왼쪽 노드, 오른쪽 노드, 부모 노드 순으로 순회함

• Inorder

  H->D->I->B->J->E->K->A->F->C->G

  왼쪽 노드, 부모 노드, 오른쪽 노드 순으로 순회함

TreeCreate함수-트리 생성

트리 생성은 큐와 연결 리스트를 통해 구현한다. 원리는 다음과 같다. 노드를 생성하고, 큐에 넣는다. 큐의 선입선출 방식을 이용해 큐에서 노드를 뽑은 다음, 해당 노드의 왼쪽 자식 노드, 오른쪽 자식 노드를 생성해 큐에 집어 넣는다. 그 후, 다시 큐에서 노드를 뽑아 자식 노드를 만들어 큐에 넣는 방식을 반복한다. 코드를 통해 알아보자.

Node *root = NULL;
void Treecreate()
{
    Node *p, *t;
    Queue q;
    create(&q, 100);

    int x;
    printf("Enter root value");
    scanf("%d", &x);
    root = new Node;
    root->data = x;
    root->lchild = root->rchild = NULL;
    enqueue(&q, root);

    while(!isEmpty(q))
    {
        p = dequeue(&q);
        printf("Enter left child: %d", p->data);
        scanf("%d", &x);
        if (x != -1)
        {
            t = new Node;
            t->data = x;
            t->lchild = t->rchild = NULL;
            p->lchild = t;
            enqueue(&q, t);
        }

        printf("Enter right child: %d", p->data);
        scanf("%d", &x);
        if (x != -1)
        {
            t = new Node;
            t->data = x;
            t->lchild = t->rchild = NULL;
            p->rchild = t;
            enqueue(&q, t);
        }
    }
}

큐에 노드가 존재할 때, 노드를 큐에서 뽑아 자식 노드를 만들고, 자식 노드를 큐에 넣는 방식이다.

preorder함수-preorder 순회를 재귀 함수로

void preorder(Node *p)
{
    if (p)
    {
        printf("%d", p->data);
        preorder(p->lchild);
        preorder(p->rchild);
    }
}

부모 노드의 데이터를 출력하고, 왼쪽 자식 노드로 옮기고, 오른쪽 자식 노드로 옮기는 방식이다. 트리 자체가 하위 노드에 또 하위 노드가 있는 재귀 형태이기 때문에 재귀 함수로의 구현이 쉽다.

postorder함수-postorder 순회를 재귀 함수로

void postorder(Node *p)
{
    if (p)
    {
        postorder(p->lchild);
        postorder(p->rchild);
        printf("%d ", p->data);
    }
}

Inorder함수-Inorder 순회를 재귀 함수로

void inorder(Node *p)
{
    if (p)
    {
        inorder(p->lchild);
        printf("%d ", p->data);
        inorder(p->rchild);
    }
}

마무리

트리의 기초와 트리 생성, 순회 코드를 알아보았다. 비선형 구조인 만큼 직관적인 트리 생성을 이해하기 힘들다. 하지만, 연결 리스트와 재귀를 활용해서 쉽게 구현할 수 있다. 다음 글에서는 위의 순회 코드를 루프를 통해 구현해보자. 루프는 이보다 이해가 어려우니 주의를 기울이자.

server component

리액트는 클라이언트단만을 컴포넌트화하는 대신, server component라는 개념을 통해 서버 영역을 컴포넌트화합니다.

(출처: https://github.com/reactwg/server-components/discussions/4)

서버 컴포넌트의 등장으로 server component 에서 데이터를 직접 가져와 client component 로 데이터를 prop 하는 형식으로 server 영역과 client 영역이 구분되기 시작했습니다.

서버컴포넌트는 컴포넌트 렌더링을 클라이언트가 아닌 서버에서 수행합니다. 서버에서 동작하기 때문에 서버 사이드 데이터에 직접 접근할 수 있으며, 유저와의 상호작용을 추가할 수 없기 때문에 클라이언트 컴포넌트와 서버 컴포넌트를 적절히 사용하는 것이 중요합니다.

서버컴포넌트는 data fetching 측면에서 기존 클라이언트 컴포넌트에서 나타나는 문제점을 해결할 수 있습니다.

1. client-server waterfall 문제 해결 : 아래처럼 컴포넌트마다 다른 데이터 fetch 를 하려고 한다는 상황을 생각해봅시다.

    function HomePage(){
        return (
            <ParentComponent>
                <ChildrenComponentOne/>
                <ChildrenComponentTwo/>
            <ParentComponent/>
        )
    }
   

   이 경우 부모 컴포넌트는 api 호출이 완료될때까지 렌더링되지 않고, 자식 컴포넌트들의 렌더링과 api 호출이 수행되지 않습니다.(waterfall 문제 -> 성능 저하)

   중첩되는 컴포넌트가 많아질수록 client-server api 호출은 많아질 것이고, 호출에 대한 응답이 완료될 때 까지 기다리는 waterfall 문제는 더욱 심각해집니다.

    //server component
    import dbConnect from 'db'; 
   
    async function MyPost(props) {
      const {userId} = props;
      const userData = await dbConnect.users.get(userId);
   
      return (
        <div>
          <div>{userData.post}</div>
        </div>
      );
    }
   

   다음은 server component 에서 데이터를 직접 fetch 하는 예시 코드입니다. server component 를 통해서 server-to-server로 데이터를 요청한다면 데이터 요청의 latency 를 줄일 수 있고, api 호출 없이 직접 DB 에 접근해 데이터를 가져올 수 있기 때문에 중첩되는 client-server api 호출을 제거할 수 있습니다.

2. js 번들 사이즈 줄이기

   서버 컴포넌트는 렌더링을 서버에서 수행하기 때문에 클라이언트단의 번들 사이즈를 감소시킬 수 있습니다. (서버컴포넌트는 서버에서 수행된 결과를 전달하기 때문에 번들을 필요로하지 않음)

server component VS server side rendering

server component 와 server side rendering 개념은 혼동하기 쉬운 개념입니다. 하지만 둘은 다른 것..! (둘은 보완 개념에 가깝습니다.)

• (Next.js 에서의 서버사이드렌더링을 기준으로) 서버사이드렌더링은 서버에서 미리 정적인 html 을 생성해주어 초기 랜딩 시 사용할 수 있도록 합니다.

• 하지만 서버 컴포넌트는 서버 영역을 컴포넌트화한것으로, 클라이언트에서는 보이지 않도록, 서버에서만 실행되도록 하는 컴포넌트입니다. (ssr 은 코드는 js 번들에 포함되어 클라이언트로 전송됨)

client component 와 server component 적절히 사용해보기

server component 내에서 client component import -> 가능

client component 내에서 server component import -> 불가

위에서 언급한 것 처럼 서버 컴포넌트에서는 유저 인터렉션 관련 작업을 수행할 수 없습니다. 따라서 서버 컴포넌트 데이터를 그 안에서 import 한 클라이언트 컴포넌트로 props 로 전달하는 방식을 사용해야 합니다. (Next.js 는 client component 를 leaf node 로 둘 것을 권장)

이런 패턴으로 배치한 컴포넌트는

1. 모든 서버 컴포넌트 렌더링

2. 클라이언트단에서 리액트가 클라이언트 컴포넌트와 1의 결과(slot) 를 렌더링, 즉 합침

의 과정으로 동작합니다.

위에서 user 의 post 를 보여주는 예시 코드를 보여줬는데, 이와 같이 유저 인터렉션이 필수적이지 않은 상황에서는 server component 를 활용하는 것이 적절하고, 글을 작성하거나 업데이트하는 등의 상호작용이 필요한 경우에는 useState 등의 hook을 사용할 수 있는 client component 를 활용해야 합니다.

참고

https://tech.kakaopay.com/post/react-server-components/

https://velog.io/@asdf99245/Next.js-app-router-%EA%B3%B5%EC%8B%9D%EB%AC%B8%EC%84%9C-%EC%A0%95%EB%A6%AC

대표적인 방식으로 feature-first 구조와 layer-first 구조가 있다.

Layer-first (feature inside layers)

‣ lib 
    ‣ src 
        ‣ presentation 
            ‣ feature1 
            ‣ feature2 
        ‣ application 
            ‣ feature1 
            ‣ feature2 
        ‣ domain 
            ‣ feature1 
            ‣ feature2 
        ‣ data 
            ‣ feature1 
            ‣ feature2

feature inside layers

각각의 layer마다 Dart 파일을 넣는 대신, 폴더를 생성한다. 서로 관련 있는 Dart 파일들을 각각의 feature 폴더에 추가한다. (widgets, controllers는 presentation 폴더 안에, models는 domain 안에)

만약 feature3를 추가하고 싶다면, 각각의 layer마다 feature3 폴더를 넣는다:

‣ lib 
    ‣ src 
        ‣ presentation
            ‣ feature1 
            ‣ feature2 
            ‣ feature3 <--
        ‣ application 
            ‣ feature1 
            ‣ feature2 
            ‣ feature3 <--
        ‣ domain 
            ‣ feature1 
            ‣ feature2 
            ‣ feature3 <--
        ‣ data 
            ‣ feature1 
            ‣ feature2 
            ‣ feature3 <--

Layer-first 구조의 단점

하나의 feature에 대해 다른 layer에 속한 파일들은 서로 멀리 떨어져 있다. 따라서 프로젝트의 여러 곳을 계속해서 이동해야 하기 때문에, 각각의 feature에 대해 작업하기 번거롭다. 또한 특정 feature을 삭제하려고 할 때, 일부 파일을 까먹을 수 있다. 각 파일들이 layer에 의해 정렬되어 있기 때문이다. 이러한 이유 때문에, 대규모의 앱을 만들 때에는 이어서 설명할 feature-first 구조를 선택하는 것이 좋다.

Feature-first (layers inside features)

feature-first 구조에서는 모든 새로운 feature마다 새로운 폴더를 생성한다. 그리고 해당 폴더 안에 layer을 집어넣는다.

‣ lib 
    ‣ src 
        ‣ features 
            ‣ feature1 
                ‣ presentation 
                ‣ application 
                ‣ domain 
                ‣ data 
            ‣ feature2 
                ‣ presentation 
                ‣ application 
                ‣ domain 
                ‣ data

이러한 구조가 더 논리적이다. 특정 feature에 해당하는 파일들이 layer로 그룹화되어 쉽게 찾을 수 있기 때문이다.

layer-first 구조보다 좋은 점

• 새로운 feature을 추가하거나 수정하고 싶을 때, 하나의 폴더에서만 작업을 하면 된다.

• 특정 feature을 삭제하려면, 하나의 폴더만 삭제하면 된다.

Common mistakes

Feature-first 는 UI에 관한 구조가 아니다!!

feature을 단순히 앱 스크린 상의 페이지로 생각할 수도 있다.

예를 들면:

‣ lib 
    ‣ src 
        ‣ features 
            ‣ account 
            ‣ admin 
            ‣ checkout 
            ‣ leave_review_page 
            ‣ orders_list 
            ‣ product_page 
            ‣ products_list 
            ‣ shopping_cart 
            ‣ sign_in

위 코드에서 각각의 feature은 앱의 실제 화면에 따라 분류되어 있다. 이처럼 UI에 의한 feature-first 구조로 접근하면 안 된다.

Feature란 무엇인가?

How to do feature-first, the right way

• domain layer부터 시작해서 model classes와 이 classes를 관리하기 위한 business logic을 찾아내라

• 각각의 모델에 대한 폴더를 생성한다

• 폴더마다 'presentation','application','domain','data' 같은 sub 폴더를 생성한다.

• 해당 sub 폴더에 필요한 파일을 넣는다

결론

feature-first 구조가 layer-first에 비해 많은 장점을 가진다. domain 주도 설계를 적용한다면, 앱 내의 서로 다른 layers와 components 간에 명확한 경계가 형성될 것이다. 이로써 후에 의존성 문제를 효율적으로 관리할 수 있게 된다.

오늘은 React, Typescript, Tailwind를 사용하는 프론트엔드 개발 환경 설정과 Express로 서버를 만들어 client에서 data fetching을 할 수 있도록 하는 과정에 대해 설명하고자 합니다.

우선 프로젝트의 루트 폴더로 이동해서 server 디렉토리를 만들고 server로 이동해주세요

Express 서버 만들기

npm init -y

위의 코드로 package.json 파일을 만듭니다. 뒤에 붙는 -y는 모든 값을 디폴트로 하겠다는 의미입니다.

npm i express
npm i nodemon

express와 nodemon을 설치해 주세요.

touch server.js

server.js 파일을 생성하고 아래와 같이 작성해주세요.

// server.js
const express = require("express");
const app = express();
const port = 8080;

app.listen(port, () => {
  console.log("Server started!");
});

서버 실행을 nodemon으로 하기 위해 package.json을 수정합니다.

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "nodemon server"
  },

이제 npm start를 입력하면 서버를 nodemon으로 실행할 수 있습니다.

하지만 실행해도 Cannot GET / 밖에 안 보일겁니다.

Frontend 환경 세팅

서버는 그대로 놔두고 터미널을 하나 더 열어봅시다.

vite를 이용해 개발 환경을 구성해봅시다
Project name은 client로 해주고
framework랑 variant는 자유롭게 설정해주시면 됩니다.
저는 React, TS + SWC를 선택했습니다.

cd client
npm i
npm run dev

위의 과정을 거쳐 npm run dev까지 입력하면 vite에서 기본 제공하는 까리한 웹페이지를 볼 수 있습니다. 하지만 저희에겐 필요없기 때문에 파일들을 정리해보겠습니다.

우선 public, assets 폴더를 통째로 지워줍니다.
App.css, App.tsx, index.css 3개의 파일은 내용을 전부 지워줍니다.

3개의 파일을 채우기 전에 tailwindcss 부터 설정해보겠습니다.

npm i tailwindcss postcss autoprefixer
npx tailwindcss init -p

tailwindcss, postcss, autoprefixer 를 설치하고 tailwind.config.js 와 postcss.config.js 파일을 생성하는 코드입니다. 왜인지는 모르지만 postcss와 autoprefixer를 설치 안하면 묘하게 tailwind가 적용되지 않으니 일단 시키는대로 전부 다 설치합니다.

순서대로 tailwind.config.js, App.css, App.tsx, index.css 파일을 아래와 같이 작성해주세요.

// tailwind.config.js
/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./pages/**/*.{ts,tsx}",
    "./components/**/*.{ts,tsx}",
    "./app/**/*.{ts,tsx}",
    "./src/**/*.{ts,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
};

 /* App.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

 // App.tsx
import "./App.css";

function App() {
  return <div className="text-red-500">COMIT</div>;
}

export default App;

마지막으로 index.css에는
http://meyerweb.com/eric/tools/css/reset/ 의 코드를 복붙해줍니다

// package.json  
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives --max-warnings 0",
    "preview": "vite preview",
    "start": "npx vite --port 3000"
  },

마지막으로 아래와 같이 start에 npx vite --port 3000을 설정해주면 npm start를 입력하는 것으로 코드를 실행할 수 있습니다. 실행하면 "text-red-500"으로 text가 빨간 것으로 보아 tailwindcss가 잘 적용된 것을 볼 수 있습니다.

혹시나 따라오는 도중에
'JSX.IntrinsicElements' 인터페이스가 없으므로 JSX 요소는 암시적으로 'any' 형식입니다
와 같은 에러가 발생하는 경우 vscode를 껐다가 다시 켜주시면 해결됩니다!

API 서버 생성 및 data fetching

다시 server로 돌아와 server.js에 간단한 API를 작성하겠습니다

const express = require("express");
const app = express();
const port = 8080;

app.get("/api/comit", (req, res) => {
  res.json({ message: "I love COMIT" });
});

app.listen(port, () => {
  console.log("Server started!");
});

/api/comit으로 GET 요청을 보내면
message: "I love COMIT"을 보내주는 간단한 API 입니다.
http://localhost:8080/api/comit 로 접속하면 확인할 수 있습니다.

이제 client에서 요청을 보내는 코드를 작성해보겠습니다.

import "./App.css";
import { useEffect, useState } from "react";

function App() {
  const [data, setData] = useState([{}]);
  useEffect(() => {
    fetch("http://localhost:8080/api/comit")
      .then((res) => res.json())
      .then((data) => setData(data));
  }, []);
  return <div className="text-red-500">{data.message}</div>;
}

export default App;

서버로 요청을 보내 data에 응답을 저장하고 data.message를 표시하는 코드입니다. 정상 작동한다면 "I love COMIT"이 보여야 하는데 아마 안 될 겁니다.

다시 server로 돌아와서 cors를 설치하고

npm i cors

const express = require("express");
const app = express();
const port = 8080;
const cors = require("cors");
const bodyParser = require("body-parser");

app.use(cors());
app.use(bodyParser.urlencoded({ extended: false }));
app.use(bodyParser.json());

app.get("/api/comit", (req, res) => {
  res.json({ message: "I love COMIT" });
});

app.listen(port, () => {
  console.log("Server started!");
});

위와 같이 server.js를 수정하면 정상 작동합니다.

위의 과정을 그대로 따라해도 잘 안된다면

client의 package.json에서 다음과 같이 proxy룰 추가해주세요

  "name": "client",
  "private": true,
  "version": "0.0.0",
  "proxy": "http://localhost:8080",
  "type": "module",

혹은 vite.config.ts 파일에서 proxy 설정을 할 수도 있습니다.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      "/api": {
        target: "localhost:8080",
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ""),
        secure: false,
        ws: true,
      },
    },
  },
});

마무리

이상 client, server 개발 환경 구축하는 과정에 대해 소개했습니다. 분명 한 번 해본 작업을 다시 정리해나가면서 글을 작성하고 있음에도 막히는 부분들이 있었습니다. 개발 환경 구축에 어려움을 느끼는 분들께 조금이나마 도움이 되길 바랍니다.

참고자료

https://www.youtube.com/watch?v=JoaTcz3K6do
https://tailwindcss.com/docs/guides/nextjs
https://abangpa1ace.tistory.com/entry/Expressjs-CORSCross-Origin-Resource-Sharing

하지만, 양질의 개발자 채용에 심혈을 기울이는 회사일수록 CS 전공 면접을 중요하게 봅니다. Kakao, Naver, Toss, 당근마켓 등 개발자가 선호하는 회사의 면접 질문에는 CS 전공 질문이 많이 등장합니다. 피상적인 질문을 하는 것이 아니라 깊게 파고들면서 질문을 합니다.

Teachyourselfcs.com에서:

소프트웨어 엔지니어에는 두 가지 유형이 있습니다. 도전적이고 혁신적인 작업을 수행할 만큼 컴퓨터 과학을 잘 이해하는 사람과 몇 가지 고급 도구에 익숙하기 때문에 그럭저럭 살아가는 사람입니다. 둘 다 스스로를 소프트웨어 엔지니어라고 부르며, 둘 다 초기 경력에서 비슷한 급여를 받는 경향이 있습니다. 그러나 유형 1 엔지니어는 가치 있는 상업적 작업이든 획기적인 오픈 소스 프로젝트이든, 기술 리더십이든 고품질의 개인 기여든 관계없이 시간이 지남에 따라 더 만족스럽고 보수가 좋은 작업을 향해 나아갑니다. 유형 1 엔지니어는 기존 방법을 통해서든, 경력 전반에 걸쳐 끊임없이 학습하여 컴퓨터 공학을 깊이 있게 배울 수 있는 방법을 찾습니다. 유형 2 엔지니어는 일반적으로 표면에 머물면서 기본 기반이 아닌 특정 도구와 기술을 배우고 기술 패션의 바람이 바뀔 때만 새로운 기술을 습득합니다. 현재 업계에 진출하는 사람의 수가 급격히 증가하고 있는 반면, CS 졸업생의 수는 상대적으로 정체되어 있습니다. 이러한 유형 2 엔지니어의 과잉 공급으로 인해 고용 기회가 줄어들고 업계에서 더 만족스러운 업무를 수행할 수 없게 됩니다. Type 1 엔지니어가 되기 위해 노력하든 아니면 단순히 더 많은 직업 안정성을 찾고 있든, 컴퓨터 과학을 배우는 것이 유일하고 신뢰할 수 있는 길입니다.

개인적인 경험으로 유형2의 개발자라 하더라도 깊이있는 개발자가 되지못하는 것은 아니라고 생각하지만, 어찌됐든 중요한 것은 채용면접을 담당하는 기업들의 시니어 개발자들은 이런 생각을 가지고 있다는 것입니다.

다행히 CS 전공 면접 질문에는 빈출 유형이 있습니다. 실무와 직결되는 내용과 필히 알아야할 지식이 정해져 있기 때문입니다. 따라서 CS 전공 면접의 파훼법은 간단합니다. 빈출 질문에 정확히(깊게) 대답하자! 컴퓨터 공학과나 소프트웨어학을 전공하면서 배우는 다음과 같은 과목들:

1. 자료구조

2. 알고리즘

3. 운영체제

4. 데이터베이스

5. 네트워크

수업을 열심히 듣고 기본적인 지식들을 쌓아가고 면접에 나오는 빈출 질문을 생각하며 공부하면 학교강의를 들으면서 자연스레 면접준비를 할 수 있을 것입니다(보통은 면접이 얼마 안남아서 부랴부랴 공부하는데 그때는 빈출 순서대로 공부하면 됩니다). 만일 이미 나는 성적은 시원히 날려버렸는데? 하는 사람도 괜찮습니다. 면접전에 이 질문들 만이라도 보고 대비해 가시면 됩니다.

빈출 프로젝트 관련 면접 질문

• 자료구조

  Q. Array를 설명하시오.

  Q. Dynamic Array를 설명하시오.

  Q. Linked List를 설명하시오.

  Q. ⭐ Array vs Linked list를 비교 설명하시오.

  Q. Queue를 설명하시오.

  Q. Stack을 설명하시오.

  Q. Stack 두 개를 이용하여 Queue를 구현하시오.

  Q. Queue 두 개를 이용하여 Stack을 구현하시오.

  Q. ⭐ Queue vs priority queue를 비교 설명하시오.

  Q. ⭐⭐BST를 설명하시오.

  Q. ⭐⭐ Hash table을 설명하시오.

  Q. ⭐⭐⭐⭐ Hash table에서 collision이 발생하면 어떻게 되는지, 해결 방법을 설명하시오.

• 알고리즘

  Q. Insertion sort코드를 작성하고 설명하시오.

  Q. Selection sort 코드를 작성하고 설명하시오.

  Q. Bubble sort 코드를 작성하고 설명하시오.

  Q. Quick sort 코드를 작성하고 설명하시오.

  Q. Merge sort 코드를 작성하고 설명하시오.

  Q. Quick sort vs merge sort비교 설명하시오.

  Q. ⭐⭐ ⭐ 가장 빠른 정렬알고리즘을 설명하시오.

  Q. n개의 Hanoi 탑을 1번 막대에서 3번 막대로 모두 옮기는 알고리즘을 구현하시오.

  Q. Fibonacci 수열의 n번 째 값을 구하는 알고리즘을 구현하시오.

  Q. ⭐⭐ binary search 알고리즘을 화이트보드에 작성하면서 설명하시오.

• 운영체제

  Q. process를 설명하시오.

  Q. ⭐⭐⭐⭐ Multi process를 설명하시오..

  Q. ⭐⭐ Multi thread를 설명하시오.

  Q. ⭐⭐ multi process와 multi thread를 비교 설명하시오.

  Q. ⭐⭐ multi process환경에서 process간에 데이터를 주고받는 방식을 설명하시오.

  Q. ⭐ Multi process/thread 환경에서 동기화 문제의 해결방안을 설명하시오.

  Q. 교착상태(Deadlock)를 설명하시오.

  Q. paging을 설명하시오.

  Q. segmentation을 설명하시오.

  Q. ⭐ 가상 메모리를 설명하시오.

• 데이터베이스

  Q. Primary key를 설명하시오.

  Q. 관계형 데이터베이스의 N:M 관계를 설명하시오.

  Q. left outer join, inner join 차이를 설명하시오.

  Q. ⭐ RDB - NoSQL을 비교 설명하시오.

  Q. ⭐⭐ Transaction을 설명하시오.

  Q. ⭐ DeadLock을 설명하시오.

  Q. Index의 필요성을 설명하시오.

  Q. ⭐⭐⭐⭐ index를 어느 column에 사용하는 것이 좋을지 설명하시오.

  Q. ⭐데이터를 검색을 할 때 hash table의 시간복잡도는 O(1)이고, b+tree는 O(logn)으로 더 느리다. 왜 index는 hash table이 아니라 b+tree로 구현되는지 설명하시오.

• 네트워크

  Q. OSI 7계층과 TCP/IP 4계층을 비교 설명하시오.

  Q. ⭐ TCP vs UDP를 비교 설명하시오.

  Q. 3-way handshake는 무엇이고 각 과정은 어떻게 되는지 설명하시오.

  Q. HTTP를 설명하시오.

  Q. ⭐⭐ HTTP resquest method 중 GET vs POST를 비교 설명하시오.

  Q. HTTP status code를 설명하시오.

  Q. ⭐⭐ www.google.com을 주소창에 입력 시, 화면이 나오기까지의 과정을 네트워크 관점으로 설명하시오.

  Q. ⭐쿠키와 세션의 차이점을 설명하시오.

  Q. 쿠키와 세션을 이용한 로그인 방식을 화이트보드에 설명하시오.

** 성균관대 선배 www.nossi.dev의 사이트를 참고함

-edited by 조준형

1. 멀티-프로세스 모델 : 크롬은 탭이 마치 독립된 브라우저처럼 작동합니다.

2. 멀티-쓰레드 사용: 각각의 탭이 각각 하나의 프로세스이고 그 안에서는 다수의 쓰레드가 사용됩니다. ex) 웹페이지 렌더링, 자바스크립트 실행, 네트워크 작업 등은 별도의 쓰레드에서 처리될 수 있습니다.

멀티 프로세스(Multi-process)와 멀티 스레드(Multi-thread)는 컴퓨터 프로그램이 작업을 병렬로 수행하는 두 가지 주요 방법입니다. 각각의 방식은 장단점이 있으며, 특정 상황에 따라 적합한 선택이 달라질 수 있습니다.

멀티 프로세스(Multi-process)

1. 정의: 멀티 프로세스는 여러 개의 독립적인 프로세스가 동시에 실행되는 방식입니다. 각 프로세스는 자신만의 메모리 공간과 시스템 자원을 가집니다.

2. 장점:

   • 격리성: 프로세스 간에 메모리와 자원이 분리되어 있어, 한 프로세스의 오류가 다른 프로세스에 영향을 미치지 않습니다.

   • 안정성: 한 프로세스의 충돌이 시스템 전체에 영향을 미치는 일이 적습니다.

3. 단점:

   • 자원 소모: 각 프로세스는 독립적인 메모리와 자원을 가지므로, 많은 자원을 소모합니다.

   • 통신 복잡성: 프로세스 간 통신(IPC)이 복잡하고 비용이 많이 듭니다.

멀티 스레드(Multi-thread)

1. 정의: 멀티 스레드는 하나의 프로세스 내에서 여러 개의 스레드가 동시에 실행되는 방식입니다. 이들 스레드는 프로세스의 메모리와 자원을 공유합니다.

2. 장점:

   • 자원 효율성: 스레드는 프로세스의 자원을 공유하기 때문에, 자원 소모가 프로세스에 비해 적습니다.

   • 통신 용이성: 같은 메모리 공간을 공유하기 때문에 스레드 간 통신이 더 간단하고 효율적입니다.

3. 단점:

   • 안정성 문제: 한 스레드의 문제가 전체 프로세스에 영향을 줄 수 있습니다.

   • 동시성 문제: 공유 자원에 대한 접근 관리가 필요하며, 이를 위한 동기화 처리가 필요합니다.

비교

• 자원 관리: 멀티 프로세스는 자원을 공유하지 않기 때문에 관리가 더 단순하지만, 더 많은 자원을 소모합니다. 반면, 멀티 스레드는 효율적인 자원 사용을 가능하게 하지만, 공유 자원에 대한 복잡한 동기화가 필요합니다.

• 성능과 오버헤드: 멀티 스레드는 컨텍스트 스위칭 오버헤드가 프로세스보다 작기 때문에 성능상 이점이 있습니다. 반면, 멀티 프로세스는 프로세스 간 컨텍스트 스위칭에 더 많은 비용이 듭니다.

• 안정성과 격리성: 멀티 프로세스는 프로세스 간 격리가 잘 되어 있어 안정성이 높습니다. 그러나 멀티 스레드는 한 스레드의 오류가 전체 프로세스에 영향을 줄 수 있어, 상대적으로 안정성이 낮습니다.

  -edited by 조준형

연결 리스트로 큐를 구현해보고, C++ 클래스로 변환해보자. 연결 리스트는 구현이 매우 쉽다. 일반 배열로 하는 것과 다르게 실제로 데이터를 입력하면 공간을 할당하고 데이터를 출력하면 데이터의 메모리 할당을 해제하면 되어 훨씬 직관적이다.

연결 리스트 큐 구현 Node

struct Node
{
    int data;
    Node* next;
}* front = NULL, *rear = NULL;

front의 위치를 연결 리스트의 맨 앞, rear를 맨 뒤로 설정하여 front를 통해 데이터가 출력되고, rear를 통해 데이터가 들어간다.

enqueue함수-데이터 입력 함수

void enqueue(int x)
{
    Node* t;
    t = new Node;

    if (t == NULL)
        printf("Queue is Full\n");
    else{
        t->data = x;
        t->next = NULL;
        if (front == NULL)
            front = rear = t;
        else
        {
            rear->next = t;
            rear = t;
        }
    }
}

새로운 노드를 할당하고, 할당이 되지 않는다면(t=NULL) 메모리에 할당할 공간이 없다는 것이기에 큐가 꽉 찼다고 판단한다. 그게 아니라면 데이터를 넣고, rear의 다음에 노드를 연결하고 rear를 해당 노드로 옮긴다.

dequeue함수-데이터 출력 함수

int dequeue()
{
    int x = -1;
    Node* t = NULL;

    if (front == NULL)
        printf("Queue is Empty\n");
    else
    {
        x = front->data;
        t = front;
        front = front->next;
        delete t;
    }

    return x;
}

front가 NULL이라면 연결 리스트가 없다는 뜻이기에 비었다고 본다. 그게 아니라면 front의 데이터를 출력하고, front의 메모리를 해제하고, next 노드로 front를 옮긴다. 일반 배열에서는 front가 데이터의 시작의 앞 인덱스를 나타냈지만, 연결 리스트에서는 front가 맨 앞 데이터를 나타낸다는 차이가 있다.

Class 활용 큐 구현

로직은 같으므로 코드만 첨부하겠다. 클래스에 size, front, rear, Q를 모두 넣어 함수 인자로 큐 구조체를 주지 않아도 되는 점이 좋다.

#include <stdio.h>

class Queue
{
    private:
        int size;
        int front;
        int rear;
        int* Q;
    public:
        Queue(int size);
        void enqueue(int x);
        int dequeue();
        void display();
        ~Queue();
};

Queue::Queue(int size)
{
    size = size;
    Q = new int[size];
    front = rear = -1;
}

void Queue::enqueue(int x)
{
    if (rear == size - 1)
        printf("Queue is Full\n");
    else
    {
        rear++;
        Q[rear] = x;
    }
}

int Queue::dequeue()
{
    int x = -1;
    if (front == rear)
    {
        printf("Queue is Empty\n");
    }
    else
    {
        front++;
        x = Q[front];
    }
    return x;
}

void Queue::display()
{
    int i;
    for (i = front + 1; i <= rear; i++)
    {
        printf("%d ", Q[i]);
    }
    printf("\n");
}

추가::Dequeue(Double Enabled Queue)

Dequeue는 front와 rear을 통해 모두 데이터를 입력할 수 있고, 뺄 수 있는 양방향 큐이다. 일반 큐가 front는 오직 데이터 출력, rear이 오직 데이터 입력 구멍이라고 하면, Dequeue는 front를 통해서도 데이터를 넣고, 뺄 수 있고, rear에서도 가능하다. 이 또한, 코드를 보면 쉽게 이해할 수 있기에 코드만 첨부한다.

#include <stdio.h>

struct Queue
{
    int size;
    int front;
    int rear;
    int* Q;
};

void create(Queue *q,int x)
{
    q->size = x;
    q->front = q->rear = -1;
    q->Q = new int[q->size];

}

void enqueueRear(Queue *q, int x)
{
    if (q->rear == q->size - 1)
        printf("Queue is Full\n");
    else
    {
        q->rear++;
        q->Q[q->rear] = x;
    }
}

void enqueueFront(Queue *q, int x)
{
    if (q->front == -1)
        printf("Queue through Front is Impossible\n");
    else
    {
        q->Q[q->front] = x;
        q->front--;
    }
}

int dequeueRear(Queue *q)
{
    int x = -1;

    if (q->rear == -1)
        printf("Queue through Rear is Impossible\n");
    else
    {
        x = q->Q[q->rear] = x;
        q->rear--;
    }

    return x;
}

int dequeueFront(Queue *q)
{
    int x = -1;

    if (q->front == q->size - 1)
        printf("Queue through Front is Impossible\n");
    else
    {
        q->front++;
        x = q->Q[q->front];
    }

    return x;
}

void Display(Queue *q)
{
    for (int i = q->front + 1; i <= q->rear; i++)
        printf("%d ", q->Q[i]);
    printf("\n");
}

int main()
{
    Queue *q;
    create(q, 5);

    enqueueRear(q, 1);
    enqueueRear(q, 2);
    enqueueRear(q, 3);
    enqueueRear(q, 4);
    enqueueRear(q, 5);
    enqueueRear(q, 6);
    dequeueFront(q);
    enqueueFront(q, 7);
    Display(q);

    dequeueFront(q);
    Display(q);
    dequeueRear(q);
    Display(q);
}

마무리

클래스와 연결 리스트로 구현해 보았다. 연결 리스트로 구현했을 때, 훨씬 직관적인 구현이 가능했음을 알 수 있다. 여담으로, 스택은 FILO 형태로 처음 들어간 데이터가 제일 늦게 나오지만 스택을 두 개 사용하면 처음 들어간 데이터가 그 다음 스택으로 제일 늦게 들어갔다가 마지막에는 제일 먼저 나오므로 FIFO를 간접적으로 구현 가능하다.

큐(Queue)는 자료구조의 한 형태로 스택과 다르게 FIFO(First In First Out) 형태의 자료구조이다. FIFO는 말 그대로 선입선출이라는 의미로 먼저 들어간 데이터가 먼저 나온다나는 것이다. 쉽게 생각하여 표를 받기 위해 줄을 서는 것으로 보면 된다. 표를 받기 위해 먼저 줄을 서면 먼저 표를 받는 방식이다. 너비 우선 탐색, 캐시 구현 등의 다양한 곳에 사용된다. 큐의 구조와 큐를 구성하는 메소드 들에 대해 알아보자.

큐 구조체

struct Queue
{
    int size;
    int front;
    int rear;
    int* Q;
};

큐에는 줄의 시작(front)와 끝(rear)이 존재하며, 데이터가 통하는 구멍이 두 개라 볼 수 있다. size는 큐가 데이터를 담을 수 있는 개수를 나타내며, Q는 할당할 배열 포인터이다.

create함수-큐 생성 함수

void create(Queue *q, int size)
{
    q->size = size;
    q->front = q->rear = -1;
    q->Q = new int[q->size];
}

선언한 큐 구조체에 사이즈를 채우고, Q에 배열을 할당한다. front와 rear는 각각 배열의 인덱스를 나타내는데 아직 큐가 비어 있으므로 -1 인덱스를 할당한다.

enqueue함수-큐 데이터 입력함수

void enqueue(Queue *q, int x)
{
    if (q->rear == q->size -1)
        printf("Queue is Full");
    else
    {
        q->rear++;
        q->Q[q->rear] = x;
    }
}

먼저 rear이 큐의 끝에 도달했는지 체크한다. 데이터가 입력될 때마다, 큐의 rear이 증가하고 그 자리에 데이터가 들어간다. rear이 마지막 인덱스에 있으면 더 이상 데이터를 넣지 못한다. 아래의 그림을 보면 이해가 쉬울 것이다.

dequeue함수-데이터를 출력하는 함수

int dequeue(Queue *q)
{
    int x = -1;

    if (q->front == q->rear)
        printf("Queue is Empty\n");
    else
    {
        q->front++;
        x = q->Q[q->front];
    }
    return x;
}

front는 쉽게 말해 표를 주는 맨 앞 점원이라 보면 된다. front 뒤에 데이터가 존재하며, front를 통해 데이터가 나간다고 보면 된다. front와 rear 사이에 데이터가 저장되는데 front와 rear의 위치가 같다면 그 사이에 공간이 없다는 뜻이기에 큐가 비었음을 알 수 있다. 그게 아니라면, front의 위치가 한 칸 밀리고, 거기에 있는 데이터를 빼낸다.

큐의 데이터가 빠져나가는데 왜 배열의 데이터가 안 밀리냐고 궁금할 수 있다. 데이터가 나가는 위치를 고정해 놓고 데이터(표를 받는 사람)이 앞으로 움직이는 것은 소요가 크다. 대신에 데이터가 나가는 위치(front, 표를 주는 사람)이 뒤로 움직이면 똑같은 효과를 front만 옮겨서 얻을 수 있어 효율이 좋다.

Display함수-데이터 출력 함수

void Display(Queue q)
{
    for (int i = q.front+1; i <= q.rear; i++)
        printf("%d ", q.Q[i]);
    printf("\n");
}

배열의 값들을 front부터 rear까지 인덱스로 출력한다.

일자 큐의 단점

위에 구현한 일자 큐, 배열의 처음과 끝이 존재하는 큐는 효율이 좋지 않다. 데이터를 넣고 빼는 것을 반복해서 rear이 배열의 끝에 도달하면 front가 밀려 앞의 데이터가 큐에서 빠져나가서 공간이 비더라도 큐는 꽉 찼다고 판단하여 입력이 불가능하다. 이렇듯 일자 큐는 일회성이다. 이를 해결하기 위한 방법이 순환 큐이다. 배열의 끝이 배열의 처음으로 이어져서 rear는 배열의 마지막에서 한 칸 움직이면 배열의 처음으로 움직일 수 있다.

순환 큐 구현하기

순환 큐의 front rear 움직임은 그저 +1을 하지 않는다. 다음과 같은 식으로 움직인다.

rear = (rear + 1) % 배열의 size

이 방식으로 front와 rear는 배열의 끝에서 한 칸 움직이면 나머지 연산에 의해 배열의 처음 인덱스로 이동하게 된다. 똑같이 배열이 빈 것은 front와 rear이 같을 때이며, 큐가 꽉 찬 것은 rear에서 이동한 곳이 front일 때이다. 아래는 empty일 때와 full일 때의 상황이다.

순환 큐 enqueue함수

void enqueue(Queue *q, int x)
{
    if ((q->rear + 1) % q->size == q->front)
        printf("Queue is full");
    else
    {
        q->rear = ((q->rear + 1) % q->size);
        q->Q[q->rear] = x;
    }
}

rear 연산을 통해 다음 이동 자리가 front와 같다면 큐는 꽉 찬 것이며, 그게 아니라면 rear을 한 칸 뒤로 옮긴 뒤 데이터를 넣는다.

순환 큐 dequeue함수

 int dequeue(Queue *q)
{
    int x = -1;

    if (q->front == q->rear)
        printf("Queue is Empty\n");
    else
    {
        q->front = (q->front + 1) % q->size;
        x = q->Q[q->front];
    }
    return x;
}

rear과 front가 같다면 큐는 빈 것이며, 그게 아니라면 front를 뒤로 밀고, 거기의 데이터를 뽑는다.

마무리

큐에 대해 알아보았다. 스택과 다르게 FIFO 방식이며, 일반 큐와 일반 큐의 일회성을 보완한 순환 큐가 있다. 다음 글에서 연결 리스트로 큐를 구현해보고, C++ 클래스로 구현해보자

전 글에서 공부한 단순 연결 리스트의 구성과 함수를 C++의 클래스로 바꿔 작성해 보았다. 전 글과 함수의 구현 로직은 같기에 코드와 실행 결과만 첨부하고자 한다.

클래스가 되며 바뀐 점

사실 Node에 대한 것은 structure을 사용하나 class를 사용하나 별 차이가 없다. LinkedList에 대해 살펴볼 점은 first의 위치이다. 기존 structure을 사용할 때는 모든 함수에 기본적으로 인자로 first를 줘서 어떤 연결 리스트의 시작점을 기준으로 하는지 필요했다. 하지만, 클래스가 되면서 연결 리스트를 객체로 생성하면, 해당 객체는 첫 시작의 주소를 알고 있으며 멤버 함수는 당연히 해당 객체의 연결 리스트에 대한 함수이기에 굳이 인자로 줄 필요가 없었다. 또한, 생성자에 create함수의 로직을 사용했다는 점에서 차이가 있다.

작성한 코드

#include <iostream>

using namespace std;

class Node
{
    public:
        int data;
        Node* next;
};

class LinkedList
{
private:
    Node* first;

public:
    LinkedList()
    {
        Node* first = NULL;
    };

    LinkedList(int A[], int n);
    ~LinkedList();

    int Count();
    void Display();
    Node* Search(int key);
    void Insert(int x, int index);
    int Delete(int index);
    void Reverse();
    int isLoop();
};

LinkedList::LinkedList(int A[], int n)
{
    Node* t;
    Node* last;
    first = new Node;
    first->data = A[0];
    first->next = NULL;
    last = first;

    for (int i = 1; i < n; i++)
    {
        t = new Node;
        t->data = A[i];
        t->next = NULL;
        last->next = t;
        last = t; 
    }
}

LinkedList::~LinkedList()
{
    Node* p = first;
    Node* t = NULL;

    while(p)
    {
        if(p)
        {
            t = p;
            p = p->next;
            delete t;
        }
    }
}

int LinkedList::Count()
{
    Node* p = first;
    int count = 0;

    while(p)
    {
        if (p)
            count++;

        p = p->next;
    }

    return count;
}

void LinkedList::Display()
{
    Node* t = first;

    while(t)
    {
        cout << t->data << " ";
        t = t->next;
    }
    cout << endl;
}

int LinkedList::Delete(int index)
{
    Node* p;
    Node* q;
    int x;

    if (index < 1 || index > Count())
        return -1;

    if (index == 1)
    {
        p = first;
        x = p->data;
        first = p->next;
        delete p;
        return x;
    }
    else
    {
        p = first;

        for (int i = 0; i < index - 1 && p; i++)
        {
            q = p;
            p = p->next;
        }

        q->next = p->next;
        x = p->data;
        delete p;
        return x;


    }
}

void LinkedList::Insert(int index, int x)
{
    Node* t = new Node;
    t->data = x;
    t->next = NULL;

    Node* p = first;
    Node* q;

    if (!p)
    {
        first = t;
    }
    else
    {
        if (index == 0)
        {
            t->next = first;
            first = t;
        }

        for (int i = 0; i < index - 1; i++)
        {
            p = p->next;        
        }
        t->next = p->next;
        p->next = t;
    }
}

void LinkedList::Reverse()
{
    Node* p = first, *q = NULL, *r = NULL;

    while(p)
    {
        r = q;
        q = p;
        p = p->next;

        r = q->next;
    }
    first = q;
}

Node* LinkedList::Search(int key)
{
    Node* q = NULL, *p = first;

    while(p)
    {
        if (p->data == key)
            return p;

        if (key == p->data)
        {
            q->next = p->next;
            p->next = first;
            first = p;
            return p;
        }
        q = p;
        p = p->next;
    }
    return NULL;
}

int LinkedList::isLoop()
{
    Node* p = first, *q = first;


    do {
        p = p->next;
        q = q->next;

        q = q ? q->next : q;
    } while(p && q && p != q);

    if (p == q)
        return 1;
    else
        return 0;
}

main함수에서의 객체 생성 후, 실행 결과

int main()
{
    int A[]={1,6,8,12,56};
    LinkedList l(A,5);

    l.Insert(2,67);

     l.Display();

    cout<<"lenght "<<l.Count()<<endl;


    l.Delete(1);
    cout<<"After deletion"<<endl;
    l.Display();
    return  0;
}

실행 결과

1 6 67 8 12 56

lenght 6

After deletion

6 67 8 12 56

올바른 결과가 나옴을 알 수 있다.

• Object Relational Mapping의 약자로 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 것

• SQL query가 아닌 직관적인 코드로 데이터를 조작할 수 있어 객체 지향 프로그래밍에 집중할 수 있다.

Sequelize

• MySQL, MaraiDB, MS SQL 등 관계형 데이터베이스를 위한 promise 기반 Node.js ORM 도구

• promise 기반으로 구현되었기 때문에 비동기 로직을 편리하게 작성할 수 있다.

Sequelize 설치

npm install sequelize sequelize-cli mysql2 // sequelize 설치
sequelize init // sequelize 초기화

sequelize init을 완료하면 해당 작업 경로에 config, migrations, models, seeders와 같은 폴더들이 생긴다.

.
├── config 
├── migrations 
├── models  
├── seeders

• config : 데이터베이스 설정 파일, 사용자 이름, DB 이름, 비밀번호 등의 정보가 들어있음

• migrations : 데이터베이스의 변화하는 과정들을 추적해나가는 정보로 실제 데이터베이스에 반영할 수 있음

• models : 데이터베이스 각 테이블의 정보 및 필드 타입을 정의하고 하나의 객체로 만들어 사용

• seeders : 테이블에 기본 데이터를 넣을 때 사용

model 생성

sequelize model:generate --name Customer --attributes id:integer,name:string, email:string, phone:string, address:string

model 옵션

• type - DataTypes : STRING, INTEGER, FLOAT, DOUBLE, BOOLEAN ...

• allowNull - Boolean : Null 허용 여부 (default: true)

• defaultValue - any : 기본값 설정(default: null)

• unique - Boolean : 유일한 값 여부 (default: false)

• primaryKey - Boolean : primary key 여부 (default: false)

• autoIncrement - Boolean : 자동으로 값을 1씩 증가 (default: false)

model 예시

customer.init({ 
id: { type: DataTypes.INTEGER, 
    allowNull: false, 
    primaryKey: true,
    autoIncrement: true}, 
name: { type: DataTypes.STRING, allowNull: false }, 
email: { type: DataTypes.STRING, allowNull: false }, 
phone: { type: DataTypes.STRING, allowNull: false }, 
address: { type: DataTypes.STRING, allowNull: true } 
}, { 
sequelize, 
timestamps: false, 
modelName: 'customer', 
});

참고자료

https://sequelize.org/

https://resilient-923.tistory.com/276

연결 리스트의 기본이 되는 단순 연결 리스트에 대해 알아보자. 단순 연결 리스트는 다음 노드에 대한 참조만을 가진 가장 단순한 형태의 연결 리스트이다. 가장 마지막 원소를 찾으려면 리스트 끝까지 찾아가야 하기 때문에(O(n)), 마지막 원소를 가리키는 참조를 따로 가지는 형태의 변형도 있다. 또한, 한 번 연결이 끊기거나, 체인이 잘 못된 경우, 모든 뒤의 데이터가 유실되는 단점이 있다.

Node구성

struct Node
{
    int data;
    Node* next;
} *first = NULL;

Node* last = NULL;

first는 노드의 시작을, last는 노드의 끝을 나타낸다. struct로 생성한 Node는 실제 요소 값을 담는 data와 다음 노드를 향한 주소 값을 담는 포인터로 구성된다.

create함수-연결 리스트 생성

void create(int A[], int  n)
{
    Node* t;
    first = new Node;
    first->data = A[0];
    first->next = NULL;
    last = first;

    for (int i = 1; i < n; i++)
    {
        t = new Node;
        t->data = A[i];
        t->next = NULL;
        last->next = t;
        last = t;
    }
}

first와 last에 대한 노드 할당을 먼저 한다. 하나의 노드이므로 first와 last가 일치하며, last의 next 노드는 없으므로 NULL이다. for루프에서 루프마다 새로운 노드를 힙에 생성하여, data에 요소 값을 넣은 뒤, last의 next 참조로 이어서 연결 리스트의 끝에 추구한다. 새로운 노드마다 끝에 붙으면 last가 되므로, 루프마다 last의 위치를 옮기는 작업이 필요하다.(last = t;)

Count함수-요소의 개수 계산

int Count(Node* t)
{
    //if (t == 0)
    //    return 0;
    //return Count(t->next) + 1;

    int x = 0;

    if (t)
    {
        x = Count(t->next) + 1;
        return x;
    }
    else
    {
        return x;
    }
}

int lCOunt(Node* t)
{
    int l = 0;
    while (t)
    {
        l++;
        t = t->next;
    }
    return l;
}

재귀함수를 사용한 버전과 루프를 활용한 버전이 있다. 둘 다 동일하게, 각 노드를 p->next를 통해 순차적으로 접근(traversing)하며, NULL(연결 리스트의 끝)이 아닐 경우, count를 1씩 늘려 반환한다. 일반적으로, t= t->next;를 통해 다음 노드에 접근한다.

Max함수-요소 들 중 가장 큰 값을 반환

int Max(Node* p)
{
    int x = INT32_MIN;
    while (p)
    {
        if (p->data > x)
            x = p->data;
        p = p->next;
    }
    return x;
}

int RMax(Node* p)
{
    int x = INT_MIN;
    if (p == NULL)
        return x;
    x = RMax(p->next);
    return (p->data > x) ? p->data : x;

}

루프를 이용한 구현은 그저 요소를 traversing하며 큰 값이 있으면 x에 담는 방식이며, 재구 방식을 살펴보면, 주요한 계산인 (p->data > x) ? p->data : x; 전에 재귀함수를 호출하여, 함수의 반환을 노드의 끝으로 미룬 뒤, 노드가 되돌아오며, 그 전의 요소의 값과 현재 노드의 값 중 큰 것을 반환한다.

Display함수-모든 노드의 요소를 출력

void Display(Node* t)
{
    while (t != NULL)
    {
        printf("%d ", t->data);
        t = t->next;
    }
}

while루프로 노드의 끝까지 진행하며, data를 printf한다.

Search함수-해당 값을 가진 노드 반환

// move to head, q를 꼬리 포인터, p를 헤드 포인터로해서 전 후의 노드를 알 수 있다.
Node* Search(Node* p, int key)
{
    Node* q = NULL;

    while (p)
    {
        if (key == p->data)
        {
            q->next = p->next;
            p->next = first;
            first = p;
            return p;
        }
        q=p;
        p = p->next;
    }
}

이 함수부터 특이하게, 두 개의 포인터를 사용한다. 머리 포인터와 꼬리 포인터로, 노드 사이를 옮겨 다니며, 해당 노드와 방금 전에 접근한 노드를 담는다. 일반적인 search는 그냥 하나의 포인터를 이용해 노드를 옮겨 다니며, 해당 노드의 data가 key와 일치하면 그 노드를 반환하면 된다. 하지만, 위에 구현한 것은 해당 key를 search 한 다음, 그 노드를 가장 맨 앞으로 옮겨와 다음 같은 key를 search할 때, 바로 첫 노드에서 반환할 수 있도록 한 "효율적인 search"방식이다.

q->next = p->next;

옮기려는 key와 일치하는 노드가 p이며, 그 전 노드의 next를 p가 아닌 p의 다음 노드로 연결하여, 노드 p를 연결 리스트에서 뺀다.

p->next = first;
p = first;

p의 다음 노드를 first로 하고, first를 p로 설정함으로써 p를 가장 맨 앞의 노드로 설정한다.

이 방식으로 다음 같은 key의 search를 한 번에 끝낼 수 있게 된다.

Insert함수-원하는 위치에 새로운 노드 추가

void Insert(Node* p, int x, int index)
{
    Node* t;
    if (index < 0 || index > Count(p))
        return;

    t = new Node;
    t->data = x;

    if (index == 0)
    {
        t->next = first;
        first = t;
    }
    else
    {
        for (int i = 0 ; i < index - 1; i++)
        {
            p = p->next;
        }
        t->next = p->next;
        p->next = t;
    }
}

노드를 insert하는 경우는 크게 둘로 나뉜다. 맨 앞에 추가하는 경우와 그 외의 원하는 위치에 삽입하는 경우이다. 먼저 맨 앞에 삽입하는 방식은 새로운 노드로의 first의 이동이 필요하하다.

     if (index == 0)
    {
        t->next = first;
        first = t;
    }

원하는 위치에 삽입하는 경우는 해당 index로 노드 이동을 한 뒤,(여기서 index는 맨 처음 노드가 1일 때의 index이다). 그 index의 노드 뒤에 새로운 노드를 추가한다.( 1 2 3의 노드 배열에 index = 3에 추가하면 1 2 3 new node가 된다.)

        for (int i = 0 ; i < index - 1; i++)
        {
            p = p->next;
        }
        t->next = p->next;
        p->next = t;

SortedInsert함수-값의 순서대로 노드를 삽입

이미 오름차순에 따라 배열된 연결 리스트에서 값을 가진 새로운 노드를 적절한 위치에 삽입한다.

void SortedInsert(Node* p, int x)
{
    Node* t, * q = NULL;
    t = new Node;
    t->data = x;
    t->next = NULL;

    if (first == NULL)
        first = t;
    else
    {
        while (p && p->data < x)
        {
            q = p;
            p = p->next;
        }
        if (p == first)
        {
            t->next = first;
            first = t;
        }
        else
        {
            t->next = q->next;
            q->next = t;
        }
    }
}

두 개의 포인터를 이용해 전 후의 노드를 할당하고, p->data가 원하는 값 x보다 큰 경우까지 traversing한다.

        while (p && p->data < x)
        {
            q = p;
            p = p->next;
        }

q에 p의 노드를 할당하고, p는 한 칸 뒤로 이동함으로써 연속적인 노드를 할당 받게 된다.

        if (p == first)
        {
            t->next = first;
            first = t;
        }
        else
        {
            t->next = q->next;
            q->next = t;
        }

p가 first노드 즉, 한 개의 노드밖에 없는 연결 리스트면 새로 생성한 노드를 앞에 추가하고, first를 해당 노드로 바꾼다.

그 외에는 새로운 노드를 p의 앞에 추가하므로, p 앞의 노드, q의 다음 포인터를 t로 설정하고, t의 다음 노드를 p로 설정한다.

Delete함수-원하는 노드 삭제

원하는 index의 노드를 삭제하고, 삭제하는 노드의 data를 반환한다.

int Delete(Node* p, int index)
{
    Node* q = NULL;
    int x = -1;

    if (index < 1 || index > Count(p))
        return -1;
    if (index == 1)
    {
        q = first;
        x = first->data;
        first = first->next;
        delete q;
        return x;
    }
    else
    {
        for (int i = 0; i < index - 1 && p; i++)
        {
            q = p;
            p = p->next;
        }
        q->next = p->next;
        x = p->data;
        delete p;
        return x;
    }
}

이 것도 동일하게, 맨 처음의 노드를 삭제하는가, 중간에 껴있는 노드를 삭제 하는 경우에 따라 나뉜다. 첫 노드를 삭제하는 경우,

    if (index == 1)
    {
        q = first;
        x = first->data;
        first = first->next;
        delete q;
        return x;
    }

첫 노드의 data를 저장하여 반환하며, first를 한 칸 뒤의 노드로 옮긴 후, 해당 노드를 삭제한다.

        for (int i = 0; i < index - 1 && p; i++)
        {
            q = p;
            p = p->next;
        }
        q->next = p->next;
        x = p->data;
        delete p;
        return x;

꼬리, 머리 포인터를 통해 해당 index의 노드로 움직인 뒤, p의 노드를 빼기 위해, 꼬리 포인터(q)의 다음 노드를 p 다음의 노드로 설정하여, p를 향한 연결 고리를 끊는다. 그 후, p의 data를 반환하고, 메모리 해제한다.

Reverse함수-연결 리스트의 순서 반전

연결 리스트의 요소 연결 순서를 뒤집는 함수이다. 방식은 크게 두 가지이다. 포인터의 연결은 그대로 놓고, 요소의 값을 임의의 배열에 저장하고, 값 자체를 뒤집어서 새롭게 저장하는 방식이 있고, 포인터의 연결 순서 자체를 바꾸는 방식(노드의 next가 다음 노드가 아니라, 그 전 노드를 향하도록 하는 방식)이 있다. 아래의 Reverse1은 값을 바꾸고, Reverse2는 포인터를 바꾼다. 일반적으로, pointer 변경 방식이 더 효율적이다.

void Reverse1(Node* p)
{
    int* A, i = 0;
    Node* q = p;
    A = new int[Count(p)];
    while (q!= NULL)
    {
        A[i] = q->data;
        q = q->next;
        i++;
    }
    i--;
    while (q!= NULL)
    {
        q->data = A[i];
        q = q->next;
        i--;
    }
}

A라는 새로운 배열을 생성하여, 임시로 연결 리스트의 요소 값들을 저장한다. 그 후, 거꾸로 루프를 돌며 노드 이동을 하며, 각각의 노드에 배열 값을 넣는다.

void Reverse2(Node* p)
{
    Node* q = NULL, * r = NULL;
    while (p!= NULL)
    {
        r = q;
        q = p;
        p = p->next;
        q->next = r;
    }
    first = q;
}

void Reverse3(Node* q, Node* p)
{
    if (p)
    {
        Reverse3(p, p->next);
        p->next = q;
    }
    else
        first = q;
}

3개의 포인터를 사용하고, 3개의 포인터는 연속적인 노드를 나타낸다. 그리고, 그 3개의 포인터는 p=p->next를 통해 미끄러지듯 순차적으로 뒤의 노드로 이동한다. 이를 sliding기법이라고 한다.

        r = q;
        q = p;
        p = p->next;

이러한 방식으로, sliding한다. r이 첫 노드, q가 그 다음 노드, p가 마지막 노드이며 순차적이다.

각 루프마다 q->next를 그 전의 노드인 r로 향하게 함으로써 노드의 포인터 연결을 뒤집는다. 왜 3개의 포인터가 필요한지 헷갈릴 수 있다. r은 당연하게도 연결을 뒤집을 그 전 노드이므로 필요하다. p는 다음 노드로의 이동을 위해 필요하다. q의 경우에는 루프마다 next가 r로 바뀌므로, q를 통해 다음 노드로 이동하려고 하면, 제대로 된 방향으로 움직이지 못한다. 그렇기에 p를 통해 노드 이동, q,r을 이용해 노드 사이의 연결을 뒤집는다.

Reverse3 함수는 같은 함수의 구현을 재귀 함수로 표현한 것 뿐이다.

Merge함수-연결 리스트의 병합

연결 리스트의 병합은 쉽다. 하지만, 오름차순으로 나열된 두 개의 연결 리스트를 병합하려면 방법이 꽤 복잡하다.

void Merge(Node* p, Node* q)
{
    Node* last;
    Node* third;
    if (p->data < q->data)
    {
        third = last = p;
        p = p->next;
        third->next = NULL;
    }
    else
    {
        third = last = q;
        q = q->next;
        third->next = NULL;
    }
    while (p && q)
    {
        if (p->data < q->data)
        {
            last->next = p;
            last = p;
            p = p->next;
            last->next = NULL;
        }
        else
        {
            last->next = q;
            last = q;
            q = q->next;
            last->next = NULL;
        }
    }
    if (p)
        last->next = p;
    if (q)
        last->next = q;
}

그림에서 보듯이, 두 개의 연결 리스트에 대해 노드 포인터 p와 q를 이용해 p와 q의 노드 값을 비교해 작은 노드에 last->next를 통해 연결을 만들고, 해당 p또는 q 노드를 한 칸 뒤로 옮기는 방식을 사용한다. 마지막에는 하나 남은 노드를 연결하여 마무리한다.

    if (p->data < q->data)
    {
        third = last = p;
        p = p->next;
        third->next = NULL;
    }
    else
    {
        third = last = q;
        q = q->next;
        third->next = NULL;
    }

첫 노드 두 개를 비교하여, 작은 쪽을 third라는 새로운 연결 리스트의 시작을 할당한다.

    while (p && q)
    {
        if (p->data < q->data)
        {
            last->next = p;
            last = p;
            p = p->next;
            last->next = NULL;
        }
        else
        {
            last->next = q;
            last = q;
            q = q->next;
            last->next = NULL;
        }
    }

p와 q의 노드가 끝날 때까지 계속 비교하며, 값이 작은 쪽으로 last->next로 연결을 만들고, 그 노드에 last를 할당한다.

IsLoop함수-연결 리스트가 루프 인지 파악

int isLoop(Node* f)
{
    Node* p, * q;

    p = q = f;
    do
    {
        p = p->next;
        q = q->next;
        q = q ? q->next : q;

    } while (p && q && p != q);

    if (p == q)
        return 1;
    else
        return 0;
}

무언가가 루프인지 끝이 있는지는 이 방법으로 쉽게 알 수 있다. 예를 들어, 원형 트랙에 두 명의 사람이 뛰고 있고, 각 사람이 뛰는 속도가 다른 경우를 보자. 만약 트랙이 일자라면 두 사람이 만날 일은 없다. 하지만, 원형이라면 언젠가 속도가 빠른 사람이 속도가 느린 사람을 다시 만나고 추월하게 된다. 이를 활용하여 루프마다 p는 한 번만 이동, q는 두 번 이동함으로써 언젠가 p와q가 만나는 지를 파악한다.

마무리

이번 글에서는 단순 연결 리스트가 무엇 인지부터 해서, 단순 연결 리스트에 필요한 다양한 함수를 구현해 보았다. 모든 함수에서 알 수 있듯이 루프를 통해 처음 노드에서 필요한 노드 또는 끝까지 매 번 traversing을 해야 했다. 구현이 단순해 지기는 하지만, 탐색이나, 조정에서 시간이 걸리기 때문에 효율적인 연결 리스트라고 하기 어려울 수 있다. 다음 글에서는 C++로 이 함수들을 구현해보고자 한다.

추상적 자료형인 리스트를 구현한 자료구조로, 일반적인 리스트는 stack 또는 heap에 연속적인 메모리 구조에 데이터를 집어넣는 방식이다. 반면에, 연결 리스트는 리스트의 요소를 담고 있는 데이터 덩어리인 Node를 기준으로, Node를 포인터를 이용해 데이터를 이어서 구현한 리스트이다. Node에는 다음의 요소 Node를 향한 포인터를 담고 있는 것이 큰 특징이다. 예를 들어 한 반에 있는 학생들의 자료를 저장한다면, 학생 하나하나의 신상명세 자료를 노드로 만들고, 1번 학생의 신상명세 자료에 2번 학생 신상명세가 어디있는지 표시를 해 놓는 방식이다. 쉽게 생각하면 자료를 비엔나 소시지마냥 줄줄이 엮어놓은 것이다.

연결 리스트 vs 리스트

연결 리스트

• 데이터 길이에 있어 유연하다. 데이터를 넣을 필요가 있을 때, heap공간에 노드를 생성해 잇기만 하면 된다.

• heap공간에만 생성할 수 있다. 포인터를 사용하기 때문에 stack에 저장하지 않는다.

• 중간에 데이터를 삽입, 데이터 삭제가 용이하다. 노드를 생성해서 이어 붙이거나, heap에서 메모리를 해제하기만 하면 된다.

• 데이터에 접근하기 위해서는 무조건 처음 노드부터 포인터를 통해 traversing해야 하기 때문에 데이터 탐색에 있어 일반 리스트에 비해 속도/효율이 좋지 않다.

리스트

• 데이터를 stack에 생성하거나 heap 생성할 수 있으며, 연속적인 메모리를 차지한다.

• 데이터 길이를 처음 선언할 때 정할 수 있어, 동적으로 데이터의 양이 변할 때, 리스트의 공간이 남거나, 부족한 현상이 발생한다.

• 데이터를 중간에 삽입하거나, 삭제할 때, 생성, 삭제 후, 인덱스를 변화시켜야 하는 불편함이 있다.

• 데이터 접근이 용이하다. 인덱스로 접근하면, 코드 한 줄로 접근할 수 있어 속도/효율 면에서 좋다.

연결 리스트의 종류

노드 끼리의 연결 구조에 따라 3가지 종류로 나뉜다.

1. 단순 연결 리스트(Singly Linked List)

2. 이중 연결 리스트(Doubly Linked List)

3. 순환 연결 리스트(Circular Linked List)

단순 연결 리스트는 데이터를 한 방향으로만 연결하여, 처음과 끝이 존재하는 형태이다.

이중 연결 리스트는 노드가 양 방향으로 연결되어 있다. 순환 연결 리스트는 처음과 끝이 이어져서 끝의 다음 포인터가 처음이 되는 형태이다.

연결 리스트의 필요 구현 사항

1. Node

2. create함수-연결 리스트 생성

3. Display함수-연결 리스트 요소 프린트

4. Count함수-리스트의 요소의 수 계산

5. Search함수-해당 요소의 위치/노드 반환

6. Insert함수-요소를 추가로 필요한 위치에 추가

7. Delete함수-지우고 싶은 요소를 삭제

8. Reverse함수-요소의 순서를 반전

추가적인 함수는 해당 리스트 유형에 따라 유연하게 작성해볼 것이며, 위의 함수들이 필수적인 함수들이라고 생각된다.

연결 리스트의 기본적인 구조

위의 사진은 연결 리스트의 가장 기초적인 구조를 시각화 한 것이다. 앞으로의 구현은 위의 그림을 기반으로 작성하며, 함수 구현마다 원리를 그림으로 모두 그려 올리지 못하기에 위의 사진을 참고하여 코드를 분석해주길 바란다.

다음 글에서, 단순 연결 리스트부터 순차적으로 구현해보도록 하겠다.

Performing side effects

단순한 GET HTTP request의 경우는 사용하기가 쉽고 복잡하지 않다. 하지만 POST request와 같은 side-effects가 발생하는 경우는 어떻게 처리해야할까?

어플리케이션에서는 CRUD를 모두 구현하는 경우가 많으며, 업데이트가 발생하는 경우 local cache 또한 업데이트하여 UI에 새로운 state를 반영해야한다. 즉, POST요청을 통해 특정 데이터에 변화가 발생하면, 새로 수정된 최신의 데이터를 클라이언트에도 동기화 해주는 작업이 필요하다.

consumer 내 provider의 state는 어떻게 업데이트해야할까? Riverpod에서는 provider가 state를 수정하는 방법을 제공하지 않는다.

이러한 처리를 위해서는 단순한 Provider를 사용하지 않고 Notifier를 활용해야한다. Notifier는 provider의 stateful widget이라고 할 수 있다. Notifier를 작성하는 코드는 다음과 같다.

// global class which will create notifier provider automatically
// using code generation
@riverpod
class MyNotifier extends _$MyNotifier {
    @override
    Result build(){
        // your logic here
    }

    // your method (change states) here
}

• 모든 Notifier는 반드시 build()매서드를 오버라이드해야한다. non-Notifier에서 사용하던 provider 생성 관련 로직을 해당 매서드 내에 작성한다.

본론으로 돌아와서, POST 요청 이후 새로운 데이터를 클라이언트에 적용하기 위해서 기존 state는 어떻게 업데이트를 해야할까? 이를 위해서는 다양한 방법을 사용할 수 있다. 총 세가지의 방법을 알아보며 장단점을 알아보자.

Updating our local cache to match the API response

첫번째 방법은 말그대로 POST 요청에 대한 응답값 자체가 최신 데이터인 경우이다. 만약 서버 로직에서 리턴 값으로 수정된 데이터를 보내준다면 이를 받아서 기존에 있던 provider state에 저장하면 된다.

Future<void> addTodo(Todo todo) async {
    final response = await http.post(
        Uri.https('your_api.com','/todos'),
        headers : {'Content-Type': 'application/json'},
        body: jsonEncode(todo.toJson()),
    )

    List<Todo> newTodos = (jsonDecode(response.body) as List)
        .cast<Map<String,Object?>>()
        .map(Todo.fromJson)
        .toList();

    // 리턴값으로 받은 최신의 데이터를 기존의 state에 저장한다.
    state = AsyncData(newTodos);
}

해당 방식은 추가적인 GET 요청없이도 provider의 state를 업데이트하여 UI에 반영할 수 있다는 장점이 있으나 서버에서 자체적으로 리턴 값이 존재하는 경우에만 활용할 수 있고, 또한 GET request가 복잡한 경우(filtering/sorting)에는 적합하지 않을 수 있다.

Using ref.invalidateSelf() to refresh the provider

또 다른 방법 중 하나는 ref.invalidateSelf()매서드를 활용하는 것이다. POST요청에 대한 리턴 값이 따로 정해져있지 않다면 사용할 수 있는 방법이며, 간단하게 invalidateSelf() 매서드를 통해서 GET 요청을 추가적으로 하는 것이다(Notifier의 build() 매서드가 다시 실행됨)

예제에서는 Todo를 담고 있는 Notifier의 build()매서드 내에서 서버로부터 List<Todo>를 받아오는 것을 가정하고 있다.

Future<void> addTodo(Todo todo) async {
  // We don't care about the API response
  await http.post(
    Uri.https('your_api.com', '/todos'),
    headers: {'Content-Type': 'application/json'},
    body: jsonEncode(todo.toJson()),
  );

  // Once the post request is done, we can mark the local cache as dirty.
  // This will cause "build" on our notifier to asynchronously be called again,
  // and will notify listeners when doing so.
  ref.invalidateSelf();

  // (Optional) We can then wait for the new state to be computed.
  // This ensures "addTodo" does not complete until the new state is available.
  await future;
}

이전의 방식과 동일하게 POST 요청을 보낸 뒤 리턴 값을 따로 받아오지 않고 기존에 존재하던 List<Todo>를 담고 있는 provider를 업데이트해주는 방식이다.

해당 방식은 직접적인 GET 요청이 있기 때문에 most up-to-date state를 유지할 수 있게 해준다. (해당 시점에 다른 유저가 todo를 추가하는 것도 반영이 가능함. 최신 상태의 데이터를 유지할 수 있음)

그러나 이러한 방식은 추가적인 GET request가 필요하다는 단점이 존재하며 이는 최적화 관련 이슈를 발생시킬 수 있다.

Updating the local cache manually

마지막으로 local cache를 수동으로 업데이트해주는 방법이 있다. 해당 방식은 백엔드의 동작을 모방하려는 시도가 존재할 수 있다.(앞서 살펴본 방식대로 추가적인 GET요청을 보내지 않고 업데이트를 하기 위해서 백엔드에서 처리하는 로직을 동일하게 프론트 단에서도 처리하도록 하는 것)

Future<void> addTodo(Todo todo) async {
  // We don't care about the API response
  await http.post(
    Uri.https('your_api.com', '/todos'),
    headers: {'Content-Type': 'application/json'},
    body: jsonEncode(todo.toJson()),
  );

  // We can then manually update the local cache. For this, we'll need to
  // obtain the previous state.
  // Caution: The previous state may still be loading or in error state.
  // A graceful way of handling this would be to read `this.future` instead
  // of `this.state`, which would enable awaiting the loading state, and
  // throw an error if the state is in error state.
  final previousState = await future;

  // We can then update the state, by creating a new state object.
  // This will notify all listeners.
  state = AsyncData([...previousState, todo]);
}

이전의 state 값을 따로 변수에 저장해주고, 이를 포함하여 새로운 todo를 뒤에 추가한 List<Todo>값을 state에 할당하여 UI를 업데이트한다. 예제에서는 immutable state를 사용했으나, 이는 필수 사항이 아닌 권장사항이다.

immutability에 대한 상세 내용은 다음의 문서에서 깊게 다룬다.

Riverpod - Why Immutability

local cache를 수동으로 업데이트하는 방식은 단 하나의 요청만 사용한다는 장점이 존재하지만 실제 서버의 데이터와 일치하지 않을 수 있다는 단점이 존재한다. 만약 동일한 시점에 다른 사용자가 데이터를 업데이트한다면(예제에서는 Todo) 이는 local cache에 반영되지 못한다.

또한 실제 백엔드의 로직을 모방하여 작성하려면 더욱 복잡해질 수 있다는 단점 또한 존재한다.

결론

POST 요청 이후에 기존에 존재하던 provider 내 상태를 어떻게 업데이트해야하는지에 대해서 알아봤다. 앱 개발을 하다보면 반드시 마주하게 되는 고민인데, 이를 패키지 문서에서 꽤나 깊게 다뤄준 점이 인상깊었다.

시나리오에 따라서 방법을 적절하게 사용하면 되지만 개인적인 생각으로는 POST 요청 이후 provider를 리프레시해주는 방식이 범용적으로 사용될 수 있는 방법인 것 같다.

개발을 처음 공부하던 시점에서는 이렇게 POST요청을 처리한 이후에 추가적으로 GET 요청을 보내는 것이 서버에 엄청난 과부하를 일으키는 건 아닐지, 너무 말도 안되는 방식은 아닌지 걱정이 많았는데, 이번에 관련 내용을 공부하면서 해당 시나리오도 일반적인 상황이라는 것을 알 수 있었다.

edited by 김동한

ListView.builder 또는 ListView.separated 등을 활용할 때 itemBuilder를 통해서 출력할 item widget을 리턴하게 되는데, 이때 마지막 부분에 footer를 넣거나 margin을 주어야하는 경우가 있다.

기본적인 ListView와는 다르게 builder 함수를 사용하는 경우 단순하게 위젯을 넣기가 곤란하다. 이는 간단하게 해당 아이템이 마지막 아이템인지 또는 첫번째 아이템인지를 체크하여 분기시키는 로직만 추가하면 된다.

다음은 itemBuilder를 활용하여 리스트의 마지막에 FooterWidget을 추가하는 간단한 예제 코드다.

구현

// data - item List
ListView.separated(
itemCount : data.length
itemBuilder : (context, index){
    // last item인지 확인하는 조건문 사용
    // 마지막 아이템인 경우에만 FooterWidget이 위젯트리에 생성된다.
    if(index == data.length -1){
        return Column(
            children: [
                ItemWidget(item: data[index]),
                FooterWidget(),
            ],
        );
    } else {
        return ItemWidget(item: data[index])
    }
}
)

다음과 같이 구현하면 마지막 아이템 아래에만 필요한 Footer 위젯이 생성된다. 동일한 방법으로 첫번째 아이템 위쪽에만 SizedBox()를 활용해서 margin을 주는 방법도 존재한다.

결론

Footer가 아니더라도 보통 리스트의 마지막 공간에는 마지막 아이템임을 표시하는 indicator를 두거나 margin을 두는 경우가 있는데 이럴 때도 활용할 수 있으며, Infinite scroll pagination 패키지를 사용할 때도 builder를 통해서 위젯을 생성하기 때문에 알아두면 여기저기 유용하게 써먹을 수 있는 방법인 것 같다.

Xcode가 기본적으로 제공하는 포맷팅은 꽤나 빈약한 편입니다.

이를 개선하기 위해서 추가적인 익스텐션을 설치하여 저장 시 자동 코드 포맷팅을 설정해보겠습니다.

Swift format for Xcode Extension 설치

우리 애증의 Xcode는 익스텐션을 설치하는 방법도 vscode 또는 Android Studio에 비해서 괴랄한 편인데요. Mac OS 패키지 매니저인 Homebrew를 통해서 설치해보도록 하겠습니다.

Format on save를 적용하기 위해서 SwiftFormat 익스텐션을 설치해야합니다. command-line tool로도 해당 익스텐션을 사용할 수 있으나, 저는 Xcode 에디터 내 익스텐션으로 활용하는 것을 추천드립니다.(편해요) 다음은 Xcode 에디터 익스텐션을 설치하는 방법입니다.

터미널을 키고 Homebrew를 통해 파일을 설치합니다.

brew install --cask swiftformat-for-xcode

설치가 완료되면 해당 파일을 열어줍니다.

파일을 열면 다음과 같은 창이 나오는데요. 주어진 설명대로 그대로 설치해줍니다.

성공적으로 설치를 완료했다면 설치된 확장프로그램 목록에 표시가 됩니다.

이제 cmd + s로 저장을 하게 되면 못난이 swift 코드를 자동으로 이쁘게 포맷팅 해줍니다.

결론

이제까지 vscode만 사용해왔기 때문에 자동 포맷팅이나 여러가지 확장자를 편리하게 설치할 수 있던 환경과는 조금 달라서 적응이 어려운 것 같습니다.

edited by 김동한

Unhandled Exception: setState() called after dispose(): _NoMoreItemState#dc583(lifecycle state: defunct, not mounted)

This error happens if you call setState() on a State object for a widget that no longer appears in the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error can occur when code calls setState() from a timer or an animation callback.

The preferred solution is to cancel the timer or stop listening to the animation in the dispose() callback. Another solution is to check the "mounted" property of this object before calling setState() to ensure the object is still in the tree.

This error might indicate a memory leak if setState() is being called because another object is retaining a reference to this State object after it has been removed from the tree. To avoid memory leaks, consider breaking the reference to this object during dispose().

앱에 타이머를 추가하거나, 애니메이션 위젯을 구현하다보면 종종 발견할 수 있는 warning 메세지이다. setState()가 실행되는 시점에 이미 해당 위젯이 dispose()된 상태인 경우, 이는 메모리 누수가 발생할 수 있다는 warning 메시지가 발생하게 된다.

이를 해결하기 위해서는 Timer를 onDispose()시 함께 dispose 해주거나 해당 위젯이 mounted인 상태일 경우에만 setState()를 호출할 수 있도록 로직을 수정해주어야한다.

다음 예제는 아이템 리스트를 불러오다가 마지막 아이템을 읽어온 후에 해당 아이템이 마지막 아이템임을 표시해주는 Text() 위젯이 AnimatedOpacity()위젯을 활용해 애니메이션 효과와 함께 출력되도록 하는 로직이다.

class NoMoreItem extends StatefulWidget {
  final String? label;
  const NoMoreItem({super.key, this.label});

  @override
  State<NoMoreItem> createState() => _NoMoreItemState();
}

class _NoMoreItemState extends State<NoMoreItem> with AfterLayoutMixin<NoMoreItem> {
  var _op = 0.0;

  @override
  FutureOr<void> afterFirstLayout(BuildContext context) async {
    await Future.delayed(const Duration(milliseconds: 400), () {
      if (mounted) {
        setState(() {
          _op = 1.0;
        });
      }
    });
  }

  @override
  void dispose() {
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Container(
      width: double.infinity,
      margin: const EdgeInsets.only(top: 16, bottom: 10),
      alignment: Alignment.center,
      child: AnimatedOpacity(
        duration: const Duration(milliseconds: 400),
        opacity: _op,
        child: Text(
          widget.label ?? 'That\'s all for now!'.hardcoded,
          style: AppTextStyles.black.copyWith(
            color: Palette.gray6B,
            fontSize: 17.sp,
            fontWeight: FontWeight.w600,
          ),
        ),
      ),
    );
  }
}

예제에서 사용한 AfterLayout과 관련된 내용은 패키지 설명을 통해 확인할 수 있다.

After Layout Package

예제에서는 afterLayout() 내에서 위젯이 위젯 트리에 생성되고 UI가 display될 때 애니메이션이 실행될 수 있도록 일정한 딜레이를 주고 setState()를 실행한다.

@override
  FutureOr<void> afterFirstLayout(BuildContext context) async {
    await Future.delayed(const Duration(milliseconds: 400), () {
      if (mounted) {
        setState(() {
          _op = 1.0;
        });
      }
    });
  }

해당 부분에서 만약 mounted를 체크해주지 않고 setState()를 호출하게 되면 만약 사용자가 setState()가 실행되는 시점에 다른 페이지로 이동하는 경우가 발생하여 dispose()가 일어나게 될 경우 setState() called after dispose() 경고가 출력될 수 있으며, 메모리 누수가 발생할 수 있다.

if(mounted)를 통해 분기처리를 해주면 setState()함수가 위젯이 dispose()되지 않은 경우에만 실행되도록 설정할 수 있다.

edited by 김동한