HyeonSi

2024.05.01(Wed.) Zustand와 함께 알아보는 전역 상태 관리의 원리

HyeonSi — Wed, 1 May 2024 10:15:36 +0900

볼떄마다 느끼는 참 개발자 스러운 곰

1. 개요

react의 전부라고 할 수 있는, 상태관리의 근본적인 원리도 모르고 쓰기는 react에게 미안하다.
실무에서 느낀 상태관리의 의의에 대해 다시 생각해 보고 싶었다.

2. 상태?

Managing State – React

The library for web and native user interfaces

react.dev

react dev docs에 따르면, 직접적으로 명령에 대해 명시하지 않고, 시각적 상태에 따라 보고 싶은 UI를 설명한다고 한다.
즉, UI 변경에 따른 결과를 말 그대로 '상태'라고 할 수있고, 그것을 저장, 변경, 컴포넌트 간 전달한다.
이때, 상태는 UI 변경점에 따른 것이므로, 상태가 변하면 UI 도 자연스럽게 업데이트 될 것이다.

3. useState

하루에도 수 십번 사용하는 근본 hook.
상태를 변경하고, 사용할 수 있도록 한다.

const [data, setData] = useState([])

첫 번째 인자로 상태값을, 두 번째 인자로 상태를 변경할 함수를 받아 구조 분해 할당으로 사용하게 된다.
근본적 원리는, useState는 초기값을 처음 인자로 받아 disoatcher 인스턴스를 생성해, 유저가 원할 때마다 반환해 준다.
- 특이점 : 우리는 처음 'const'로 useState를 구조분해할당 했기 때문에 data가 직접 바뀌지는 않는다.
- 전역에 생성된 closuer가 useState가 실행될 때마다 초기값을 비교하고 할당해 준다.
- setState가 실행되면 받은 인수로 closuer의 값을 변경시켜 주고, 리렌더링을 실행하며, 바뀐 값을 useState가 가져온다.

4. 전역 상태 관리

결국, useState의 값은 한 컴포넌트 안에서만 사용가능하다.
같은 상태를 위계가 다른 컴포넌트에서 사용하려고 하거나, 상태를 props 드릴링 하다보면 상태의 생명주기를 알 수 없게 되고, 무분별한 리렌더링이 일어난다.
그래서 한번 선언한 상태를 다른 컴포넌트에서도 사용하기 위해 전역 수준에서 상태를 관리하기도 한다.
기본적인 방법으로 Context API를 사용할 수 있다.
- Context API는 '의존성 주입'을 위한 API 이다.
- ContextProvuder 컴포넌트를 만들어 내부에 useState를 사용해 상태를 만들어주고 value를 props로 받는다.
- value가 바뀔 때마다 상태를 변경해 주고 다시 바뀐 상태를 반환 한다.
- 이후 ContextProvuder 아래의 children들은 useContext hook으로 상태에 접근이 가능하다.
- 단점 : props의 value가 바뀔 경우 모든 children들은 리렌더링 된다. 결국 상태이기 때문이다. 그래서 불필요한 리렌더링을 막기 위해 memoization이 필수적이다. 결국, 어디서 memoization이 일어나고, 상태가 변경하는지를 정확히 알지 못하게 되는 경우가 프로젝트 사이즈가 커지면 종종 일어나기 때문에 상태의 생명주기를 어지럽히는 요인이 된다.

5. Zustand

redux보다 간단하고, 필요 없는 렌더링을 조절하기가 간단한 전역 상태 관리 라이브러리이다.

Zustand

zustand-demo.pmnd.rs

import { create } from 'zustand'

const useStore = create((set) => ({
  count: 1,
  inc: () => set((state) => ({ count: state.count + 1 })),
}))

function Counter() {
  const { count, inc } = useStore()
  return (
    <div>
      <span>{count}</span>
      <button onClick={inc}>one up</button>
    </div>
  )
}

useState와 마찬가지로, 초기값, set 함수의 동작을 create 하고, hook으로 어디서든 접근이 가능하다.
일반적으로 create로 만든 hook 들을 한 파일에서 관리하고, 사용해야 할 컴포넌트에서 가져와 사용한다.

6. 적절한 상태관리란?

상태의 '범위'를 알고 사용하는 것이 중요하다. 각 스코프에 맞는 사이즈의 상태를 만들고, 상태의 생명주기를 개발자가 마음대로 조절할 수 있어야 한다. 불필요하게 모든 상태를 전역으로 사용하려 한다거나, 무분별한 props 드릴링으로 상태를 컴포넌트 간에 전달하는 방향은 다른 개발자들을 괴롭히는 일이다.
필요에 의한 상태만을 만든다. 상태로 관리해야 할 것은 'UI 변화에 따른 값'이다. 한번 선언해 놓고 더 이상 변하지 않는 값을 가진 경우나, 초기값만 이 중요한 경우라면 굳이, 상태로 만들지 않고 선언해서도 충분히 사용할 수 있다. 불필요한 리렌더링을 줄이는 것도 큰 의의가 있다.
여러 가지 전역 상태관리 라이브러리를 혼용해서 사용하지 않는다. 상태의 생명주기를 더욱 따라가기 힘들게 할 뿐이다.
의존적이지 않고, 결합적이지 않은 코드를 작성하기 위해서는 전역 상태 관리를 사용하지 않는 것이 좋다. 필요에 따라 사용할 수 도 있지만 분명, 재사용에 큰 제약을 만들 것이다.

2024.04.27(Sat.) <React Query를 통한 state에 관한 고찰 >

HyeonSi — Sat, 27 Apr 2024 14:59:35 +0900

0부터 1까지만 알아보자

1. 개요

react query를 왜 사용하는가? 에 대한 질문은 너무 쉽게 할 수 있다. 왜냐고? 캐싱, 최적화, 언제 어디서든 서버에서 최신의 상태를 가져다가 전역으로 사용할 수 있는 매우 편한 라이브러리가 아닐수 없다! 하지만 세상에 완벽한게 어디있나, 분명 그에도 단점은 존제 할 것이다. 그래서 단점을 찾기 전에 가장 근본적인 질문부터 하나하나 알아 보려고 한다.

2. Query

- 많은 프론트 개발자들은 query와 친하지 않다.(사실 뭔지도 잘 모르겠다. 하지만 직접 쿼리를 써보라고 하면 또 쓴다...!? 어째서..)

- query : 질의

- DB와 통신에 필요한 요청을 질의하는 것을 말한다.

- 이를 위해 만들어지는 질문을 SQL이라고 부른다.

3. react-qurey

- 서버 상태관리를 위한 라이브러리

- fetching, caching, synchronizing, updating을 간단하게 hook으로 할 수 있다.

- 기존의 미들웨어는 복잡한 로직으로 만드는 과정이 쉽지않고, 이를 위해 보일러 플레이트를 만들어 여러 프로젝트에 적용한다고 해도, 코드의 양도 많아진다. 이를 react query는 대체할 수 있다.
(하지만 여기서 단점, 이렇게 내부 로직을 잘 알고 쓴다면 상관없지만, 다양한 hook들이 어떠한 방식을 통해 데이터를 다루고 있으며 데이터의 흐름을 직접 제어할 수 없다는 점에서 단점이 있다!)

- QueryClientProvider가 React Context API를 사용해 가장 최상단에 존제하기 때문에, 전역으로 사용할 수 있는 서버의 상태가 된다.

4. react-qurey의 기본 동작 순서

상태 확인
- 데이터의 상태를 확인한다.
- 데이터 상태의 종류
  - fresh : 최신화 된 데이터. 혹은, 아직 staleTime이 지나지 않아서 개발자가 보장하는 최신화된 데이터
    -> 이미 최신화된 데이터라면, 중복으로 네트워크 요청을 막음
  - fetching : 서버와 데이터를 통신하는 중
  - stale : 최신화 되지 않은 옛날 데이터 -> react qurey는 이 경우 다시 fetching -> fresh한 데이터로 상태를 바꾸려 한다.
  - delete : 삭제된 데이터. 혹은, cacheTime이 지나 케시에도 없는 데이터
상태에 따라 서버와 통신

5.간단한 원리

- 서버와 통신하여 데이터가 최신인지를 확인한다.

- 이때, 최초의 통신이 발생한다. 그래서 데이터가 최신인지를 확인하게 된다. 그리고 이는 state로 관리된다. (useQurey)

- 최신이라면, 캐싱하고 알맞는 queryKey에 바인딩 된다.

- 만일 데이터가 stale하여 다시 서버와 통신이 일어나 데이터가 최신화 되면, state도 바뀐 것이므로 리렌더된다.

- 더 자세한 내용은 아래 글 참고

React Query의 구조와 useQuery 실행 흐름 살펴보기 | 카카오엔터테인먼트 FE 기술블로그

함성준(kevin) 개발에는 인생(喜怒哀樂)이 담겨있습니다. 커피 좋아합니다.

fe-developers.kakaoent.com

6. state와의 접점

- react query는 데이터 패칭 라이브러리가 아니다.

Thinking in React Query

In this talk, we will learn how a different mindset can help us understand React Query and work with it efficiently.

tkdodo.eu

[번역] React Query 적으로 사고하기

React Query Maintainer인 Tkdodo가 알려주는 리액트 쿼리적으로 사고할 수 있는 3가지 요소들을 다루어봅니다.

velog.io

- 비동기 상태 관리자 (Async State Manager) 라고 한다.

- 클라이언트 단에서는 네트워크를 통신해서 불러온 데이터도 '상태'로 관리하고 UI에 필요한 데이터도 '상태'로 관리하게 된다. 필요에 따라 스코프를 넓혀 '전역 상태'로도 관리하게 된다.

- 프로젝트의 사이즈에 따라 전역상태가 관리가 힘들정도로 많아 진다면 혹은, 필요없는 상태들까지 전역으로 관리하거나 하는 행동은 코드 가독성과 유지보수에 치명적이다. (진짜 고통스럽다. 기능 추가 혹은 수정에 시간을 오래 쓰기보다 상태들을 따라가 찾는데 오랜 시간을 쓰게 된다.)

- 그래서 일단, 서버 상태와 클라이언트 상태를 분리시키는데 의의가 있다.

- 그리고 서버 상태는 효율적으로 관리될 필요가 더욱 크다. 필요할때 데이터를 불러 상태를 변경해 최신화 하고, 이미 최신의 데이터를 유지하고 있다면 상태를 업데이트 할 필요가 없어진다.

- 이때, 데이터의 최신화 여부가 상태의 업데이트를 함께 다뤄준다는 점이 react query의 최고 장점 되시겠다.

2023.08.11(Fri.) <Atomic Design Pattern>

HyeonSi — Sat, 12 Aug 2023 00:13:17 +0900

작은 것들을 모아 정리 하는 느낌이랑 비슷한 느낌이라 가져온 짤입니다 틀니 딱딱딱! (윈도우98입니다)

1. 문제의 발단

RN 강의를 듣던 중 강사님이 참 폴더 구조들을 정리를 잘한다고 생각했다.
지금 프로젝트도 나름 정리를 하여 사용한다고 생각했지만, 뭔가 10% 부족하다고 느꼈다. 폴더 구조에 대한 정답은 없기 때문이다.
그래서 그나마 정답에 가까운 것을 찾아 보려고 한다.

2. Atomic Design Pattern?

React의 구조는 수많은 컴포넌트로 되어 있다. 그러므로 똑같은 코드를 여러 번 사용하는 극한의 재사용성을 보여줄 수 있다.
하지만 아무리 유용한 컴포넌트라도 어디에 있는지 찾지 못 하면 낭패다. 마치 침대 위 TV리모컨처럼 말이다.
그래서 유형별로, 혹은 특정 공통점을 기준으로 잘 정리해 두려고 한다. 이때 atomic design pattern은 '디자인'을 중점적으로 이용하여 정리하고 그를 먼저 만들고 조립하는 디자인 시스템을 뜻한다.

3. 그림으로 보는 Atomic Design Pattern

출처 https://uxdesign.cc/atomic-design-2022-what-we-can-learn-from-eames-and-other-design-giants-4d8e2f579daa

이렇게 자동차가 만들어지는 것처럼 가장 작은 단위 (작은 나사, 철 프레임등)가 뭉쳐 하나의 기능을 하는 의미 있는 구성품이 되고, 그것들이 모여 기능을 하는 프로젝트를 구성하게 된다.

출처 : https://actgovproject.bitbucket.io/

웹버전에서 보면 이런 그림이다.
작은 기능을 하는 태그, 디자인에 필요한 아이콘 등이 합쳐저서 하나의 기능을 하는 작은 컴포넌트가 되고, 그들이 모여 큰 레이아웃을 형성하게 되면서, 데이터를 넣으면 큰 페이지가 된다.

4. 어떻게 진행 되는가

1. Atoms : 가장 작은 디자인 요소의 단위
2. Molecules : 적어도 하나의 기능은 할 수 있는 컴포넌트 단위
3. Organisms : 하나의 기능을 하는 요소들을 합쳐 디자인적 요소까지 더한 유저들에게 의미를 부여한 단위
4. Template : 데이터를 연결하기 전의 레이아웃 단위
5. Page : 유저들이 보는 단위

5. 실전편

 atomic-design-pattern-test
 ┣  components
 ┃ ┣  atoms
 ┃ ┣  moecules
 ┃ ┣  organisms
 ┃ ┗  templates
 ┗  pages

정말 직관적인 네이밍
가끔 헷갈리는 부분이 있다. 무엇이 molecules이고, 무엇이 organisms 일까??
- 나는 너무 고민하지 않기로 했다. 그저 '우리'가 보기 편하면 모든 것이 완벽하다고 생각했기 때문에 기획자와 디자이너와 적당한 합의 후에 디자인 시스템부터 나누어 생각했다.
- 우리가 이 컴포넌트는 molecules라고 말하면 molecules인 것이고, organisms이면 organisms인 것이다. 그래서 우리들만의 규칙을 만들어 나누어 주었다. (ex: 결제나 비즈니스 로직이 들어간 컴포넌트면 organisms로 보자)

6. 결론

정답은 없다. 이것 또한 개발을 그리고, 구조를 편하게 정리하고 보기 위해 만드는 디자인 패턴일 뿐이니까 말이다.
결국 우리가 선택한 구조는 페이지를 기준으로 기능적인 부분을 때서 나눠놓은 패턴이 되었다(아, 정리했는데 ㅎㅎ)
프로젝트마다 어떤 디자인 페턴을 선택하는지가 이후에 프로젝트의 규모가 거대해졌을 때도 큰 영향을 미치니, 최대한 확장성과 정확한 규칙을 토대로 만들어 가는 것이 좋을 것 같다.

2023.07.27(Tue.) <얻은 알고리즘 문제 : 해싱, 시간파싱>

HyeonSi — Thu, 27 Jul 2023 23:19:11 +0900

한 번 사용한 최초문자

문자열에서 한번만 사용한 문자를 찾으려고 합니다. 매개변수 s에 문자열이 주어지면 한번만 사용한 문자 중 문자열에서 가장 먼저 나타난 문자의 인덱스 번호를 반환하는 프로그램을 작성하세요. 인덱스는 1부터 시작합니다. 한번만 사용한 문자가 없을 경우 -1를 반환하세요.

s answer

"statitsics"	3
"aabb"	-1
"stringshowtime"	3
"abcdeabcdfg"	5

제한사항: • 문자열 s의 길이는 100을 넘지 않습니다. • 문자열은 소문자로만 이루어져 있습니다.

입력예제 1 설명 : 한번만 사용한 문자는 a, c이고, 문자열에서 먼저 나타난 것은 a이고 인덱스는 3입니다.

const func = (string) => {
  // 주어진 문자열을 각 문자로 분리하여 배열로 만든다.
  const strArr = string.slice().split('');
  // 결과를 저장할 객체를 생성한다.
  const result = {};

  // strArr 배열의 각 문자에 대해 처리,
  for (let i = 0; i < strArr.length; i++) {
    const currentChar = strArr[i];
    // 현재 문자가 result 객체의 프로퍼티로 존재하는지 반복문으로 확인한다.
    const existingValue = result[currentChar];

    // 현재 문자의 값이 존재하는지 확인한다.
    // 존재하는 경우 해당 값을 1 증가시킨다.
    // 존재하지 않는 경우(빈 값인 경우) 새로운 키를 생성하고 값을 1 준다.
    result[currentChar] = existingValue ? existingValue + 1 : 1;
  }

  // 0일 경우 -1이기 때문에 중간에 한번 걸러준다.
  const filterFunc = (result) => {
    return result === 0 ? -1 : result;
  }
  return filterFunc(Object.values(result).findIndex((el) => el === 1) + 1);
}

2023.07.12(Wed.) <React 항상 z-index 최상위에 있는 Modal 만들기>

HyeonSi — Wed, 12 Jul 2023 21:56:29 +0900

대단한 기술을 하찮은 곳에 사용합니다. 하지만 가장 중요하죠.

1. 문제의 발단

스타일 가이드를 고치면서 확인하니, z-index가 모든 alert, modal등에서 꼬여있다.
가장 최상의 단위를 잡고, 위계를 생각하며 기획이 되어야 하지만 추가되는 사항이 많고, 리팩토링 하지 못 해서 꼬여있었다.
그래서 임시로 추가할 alert에 z-index를 9999로 설정하고 만들었다.
하지만 하위 노드에서 이미 modal을 만들고, 그것을 기준으로 다음 컴포넌트들을 만들어 z-index와 상관없이 최상위로 올라오지 않는 이슈가 있었다.
그래서 아예 처음부터 가장 최상위에 올려서 렌더링 하기로 하였다.

2. Potal?

지정한 DOM의 외부에 렌더링을 하게 만들어주는 함수
첫 번째 인자에는 컴포넌트, 두 번째 인자로 DOM을 넣어준다.

3. 예시

import { Dispatch, SetStateAction, useEffect } from 'react';
import { createPortal } from 'react-dom';

export function Alert({
  children,
  setState,
}: {
  children: React.ReactNode;
  setState: Dispatch<SetStateAction<boolean>>;
}) {
  // useEffect로 timeout을 걸어 3초 뒤 자동으로 꺼지게 만든다.
  useEffect(() => {
    const timeout = setTimeout(() => {
      setState(false);
    }, 3000);

    // 다시 alert가 열리더라도, 처음 timeout을 초기화 하여 가장 나중에 열린 alert를 3초 유지시킨다.
    return () => clearTimeout(timeout);
  }, []);

  // 가장 최상위 DOM을 선택한다.
  const modalRoot = document.getElementById('modal-root');
  
  // createPortal로 return한다. 
  return createPortal(
    <Backdrop onClick={() => setState(false)}>
      <div onClick={(e) => e.stopPropagation()}>
        {children}
      </div>
    </Backdrop>,
    modalRoot!
  ) as any;
}

4. 소감

처음 스타일 가이드를 잡을때, z-index도 따로 설정에 잡아 놓는 것이 가장 좋겠다.
예를 들어, 항상 최상위에 오는 Backdrop을 최상위, 그 아래로 header, footer 등으로 말이다.
그리고 상수로 z-index를 관리하면 중간에 다른 단계를 넣거나 수정하더라도 편하게 사용할 수 있다.

2023.06.29(Tue.) <Blob Type Response의 에러 처리>

HyeonSi — Thu, 29 Jun 2023 21:07:33 +0900

그만 둬요 제발. 사실 제가 했습니다. 죄송합니다. 실수에요. 근데 정말 어 할만한 상황이었어요. 들어보세요.

1. 문제의 발단

axios response type을 'Blob'으로 받아 서버에서 엑셀 다운로드를 가능하게 하는 API를 연결하는 작업을 하고 있었다.
받는 타입을 Blob으로 해야 브라우저의 다운로드 기능까지 연결되어 처리가 가능하다.
기능은 원하는 방향으로 잘 작동하나 문제는 에러가 났을 경우이다.
response도 blob 형식으로 온다. 그래서 서버와 합의한 error code를 뽑아 상황에 맞는 에러 처리가 되지 않았다.
액세스 토큰이 만료되었을 때, axios 인스턴스에 설정해 놓은 대로 reissueToken이 안 되는 현상을 발견하여 확인해 보니, 토큰 만료 시 나오는 에러 code를 잡지 못하고 있었다.

2. 처음 상황

export async function getData() {
  return await axiosInstance.get(`${baseURLV3}/data`, {
    responseType: 'blob',
  });
}

위와 같이 api를 호출하는 코드를 만들어 놓은 상황
에러가 날 경우 Blob 객체 형태로 error를 받음

3. 해결법

export async function getData() {
  return await axiosInstance.get(`${baseURLV3}/data`, {
    responseType: 'blob',
  });
}

...
catch(err) {
	const errorResponse = JSON.parse(await err.response.data.text());

	if(errorResponse.code === '토큰이 만료 되었을 때 나는 에러 코드') {
		return reissueToken()
	} else {
		return console.log('is not token issue')	
	}
}

JSON.parse(await error.response.data.text()); 으로 다시 처리하면 우리가 알던 방식 그대로 error의 형태를 바꿀 수 있다.
대신, 비동기로 작동한다는 것!

2023.06.26(Mon.) <UX/UI 아티클 정리>

HyeonSi — Mon, 26 Jun 2023 23:22:05 +0900

비즈니스 모델 vs 사용자 경험

비즈니스 모델 : 어떠한 상품을 소비자에게 제공할때, 어떻게 이윤을 추구 할 것인가?
사용자 경험 : 사용자가 생각하는 제품을 이용할때 축적하게 되는 경험

개발자가 생각하는 관점 vs 유저가 생각하는 관점

유저에게 어디까지 친절할 것인가? → 사용하지도 않는 버튼으로 가득찬 TV 리모컨
‘개발자 지식의 저주’ → 개발자와 똑같이 유저가 모든 환경과 기능을 이해하고 사용할 것이라는 착각. Qa 때도 자주 발생한다.
통제감 → 단순하게 만들어야 유저는 제품에 대해 통제감을 느끼고 사용할 의지를 느끼게 된다.
- 디자인도 중요하지만, 만들어지는 방식, 사용법등 제품에 대한 모든 것을 단순화 하는 것이 더욱 도움이 된다.
- 조니 아이브 : 본질적이지 않은 부분을 제거하여 그 제품의 본질만을 남기는 것 = 단순화
좋은 사용자 경험이란? → 비즈니스 모델을 생각한 (중점이 되는) 유저 사용감의 상승
- 즉, 개발자도 비즈니스 모델을 이해하고, 비즈니스 모델을 극대화 하는 사용자 경험을 만들어야 한다. 이것이 단순화가 될 수 도 있고, 오히려 복잡해 질 수 도 있다.
- 사용자 경험에 절대적인 명제는 없으며, 비즈니스 모델, 로컬의 문화 등의 모든 부분을 종합하여 고려해야 한다.

내가 사용자 경험을 말할 때

네이버 활용백서

네이버 PC 메인

처음 애니메이션 및 스크롤 애니메이션으로 시선을 끔
텍스트는 양을 줄이고 기능을 강조
기능확인 탭 → 네비게이트 버튼 있음 (최상, 하단에서는 사라짐, 컨텐츠를 보고 있을 경우에만 존제)
개인설정 탭 설명은 동영상으로 대체 → 너무 많은 정보를 담고 있고, 자신이 관련없는 개인설정일 경우에 확인 할 필요가 없는 컨텐츠이므로
견해
- 장점 : 화려함. 설명이 부족한 부분이 없고 필요한 정보만을 제공중. 어떤 연령의 이용자가 보아도 어느정도 납득이 가는 컨텐츠
- 단점 : 유저가 보지 않을 경우 말짱 도루묵 → 그만큼 사용하기 어려운 검색 포털 → 검색 포털이 이렇게 어려울 필요가 있을까? → 비즈니스 모델과 관련이 있을 것으로 예상, 주된 비즈니스 모델이 ‘광고’인데 네이버 광고는 블로그, 카페 등으로 이루어진 컨텐츠형 광고가 많은 것으로 생각됨. 그래서 그런 광고의 노출도를 올리고 광고 컨텐츠의 생산을 위해 어쩔 수 없는 경우가 아니였을까 생각됨.
- 그런거 치고도 꽤 깔끔하고 직관적이라고 생각됨. 아마 기업 이미지나 이때까지 사용하던 사용자 경험이 큰 영향을 주고 있다고 생각됨.

2023.06.25(Sun.) <React 공용 컴포넌트에 관한 고찰 1 : Button>

HyeonSi — Sun, 25 Jun 2023 16:05:40 +0900

제 코드가 어디선가 유출되고 있나 봅니다. 똑같군요.

1. 문제의 발단

디자이너님과 함께 정형화되지 않았던 스타일 가이드를 다시 고치고, 공용 스타일로 사용되지 않던 컴포넌트들을 다시 통일시키고 있다.
스타일도 통일 시키고, 그에 따라 필요한 인자들을 넘겨주어 정형화되고 완벽한 어디에도 사용할 수 있는 컴포넌트를 만드는 과정에서 깨달은 것들을 적어본다.

2. Button Size

가장 기본적으로 사이즈로 나눌수 있다.

width는 fit, height를 3가지 종류로 나눴다.

const Button = styled('button', {
  base: css`
    ${apply`border-1 rounded-[4px] px-4 bg-[#2ecc71] border-2 text-white bg-cyan-500 shadow-lg shadow-cyan-500/50`};
  `,
  variants: {
    size: {
      small: `h-[33px]`,
      medium: `h-[41px]`,
      large: `h-[49px]`,
    },
  },
  defaults: {
    size: 'large',
  },
});

export default function Projects() {
  return (
    <div className={tw`flex justify-center items-center gap-2 mt-[50vh]`}>
      <Button size='small'>Small</Button>
      <Button size='medium'>Medium</Button>
      <Button>Default Large</Button>
    </div>
  );
}

가장 기본적인 스타일만을 넣은 버튼이다.
대부분 2 ~ 3개 정도의 버튼 스타일을 쓴다.

3. outlined

import { styled } from '@twind/react';
import { apply, tw } from 'twind';
import { css } from 'twind/css';

const Button = styled('button', {
  base: css`
    ${apply`border-1 rounded-[4px] px-4 bg-[#2ecc71] border-2 text-white bg-cyan-500 shadow-lg shadow-cyan-500/50`};
  `,
  variants: {
    size: {
      small: `h-[33px]`,
      medium: `h-[41px]`,
      large: `h-[49px]`,
    },
    variant: {
      normal: ``,
      outlined: `border-[#2ecc71] text-[#2ecc71] bg-white`,
    },
  },
  defaults: {
    variant: 'normal',
    size: 'large',
  },
});

export default function Projects() {
  return (
    <div className={tw`flex justify-center items-center gap-2 mt-[50vh]`}>
      <Button>Normal</Button>
      <Button variant='outlined'>Outlined</Button>
    </div>
  );
}

색상 반전의 느낌으로 스타일링을 바꾼다.
기본값을 잘 넘겨줘야 한다.

4. hover

import { styled } from '@twind/react';
import { apply, tw } from 'twind';
import { css } from 'twind/css';

const Button = styled('button', {
  base: css`
    ${apply`border-1 rounded-[4px] px-4 bg-[#2ecc71] border-2 text-white bg-cyan-500 shadow-lg shadow-cyan-500/50`};
  `,
  variants: {
    size: {
      small: `h-[33px]`,
      medium: `h-[41px]`,
      large: `h-[49px]`,
    },
    variant: {
      normal: ``,
      outlined: `border-[#2ecc71] text-[#2ecc71] bg-white`,
      hover: `transition duration-150 ease-out hover:(ease-in bg-red-500)`,
    },
  },
  defaults: {
    variant: 'normal',
    size: 'large',
  },
});

export default function Projects() {
  return (
    <div className={tw`flex justify-center items-center gap-2 mt-[50vh]`}>
      <Button>Normal</Button>
      <Button variant='hover'>Hover</Button>
    </div>
  );
}

hover를 넣어주고 똑같이 만들어 준다.
outline에 hover도 가능하다.

import { styled } from '@twind/react';
import { apply, tw } from 'twind';
import { css } from 'twind/css';

const Button = styled('button', {
  base: css`
    ${apply`border-1 rounded-[4px] px-4 bg-[#2ecc71] border-2 text-white bg-cyan-500 shadow-lg shadow-cyan-500/50`};
  `,
  variants: {
    size: {
      small: `h-[33px]`,
      medium: `h-[41px]`,
      large: `h-[49px]`,
    },
    variant: {
      normal: ``,
      outlined: `border-[#2ecc71] text-[#2ecc71] bg-white`,
    },
    isHover: {
      normal: ``,
      true: `transition duration-150 ease-out hover:(ease-in bg-red-500)`,
    },
  },
  defaults: {
    variant: 'normal',
    size: 'large',
  },
});

export default function Projects() {
  return (
    <div className={tw`flex justify-center items-center gap-2 mt-[50vh]`}>
      <Button>Normal</Button>
      <Button variant='outlined' isHover>
        Hover
      </Button>
    </div>
  );
}

props 종류를 2개로 찢은 다음에 2개 다 넣어준다.

5. 소감

생각해 보니 button에 스타일 제외, 다른 속성과 이벤트를 넣을 것이 없다..! (onClick이 전부 아닌가...?)
이후에 모달, 팝업, warring 등에는 다양한 인자를 props로 넘겨 사용할 수 있을 것이다.

2023.06.23(Fri.) <노션 주간 업무 보고 템플릿 공유>

HyeonSi — Fri, 23 Jun 2023 20:03:08 +0900

일주일치 노고를 씻겨주는 때껄룩. 보고 힐링 합시다. 의미는 없어요

1. 문제의 발단

주간 보고를 간단하게 표로 만들어 공유만 했는데, 잘 파악하기 어려웠다.
그래서 템플릿을 찾으니, 잘 없어서 만들었다. 이거 한 장으로 CTO님께 이쁨 받는 글 잘 쓰는 개발팀, 동료들에게 생색 한 번 더 내는 개발자가 되자.

2. 노션 링크

주간 업무

A new tool for teams & individuals that blends everyday work apps into one.

outrageous-tiger-d2b.notion.site

3. 유의점

위 창에서 새로 만들기를 하면 날짜를 더 늘릴 수 있고, 자동으로 매월 1일이 되면 다음 탭이 생깁니다.

이때, 생성되는 탭을 수정하고 싶다면 위 그림처럼 새로 만들기 옆의 화살표를 누르고 템플릿 자체를 수정해야 합니다. (탭 안에 들어가서 수정하면 그 탭만 영향을 받고, 다음에 생성될 탭은 영향을 받지 않습니다.)

그리고, 그 템플릿 편집으로 들어가 '김코딩' 옆의 + 버튼을 눌러 동료의 이름을 입력합니다. 그리고 '생성자' 필터도 그 동료의 이름으로 바꿔 줍니다.
아래의 표에서 생성자도 동료의 이름으로 바꿔줍니다.
귀찮다면, 동료에게 직접 생성하라고 합니다. (기본값이 저 버튼을 누른 사람이기 때문에 + 버튼을 눌러 이름만 추가해 주면 나머지는 자동으로 됩니다.)
위의 편집을 하지 않으면 올바르게 사용할 수 없습니다!

4. 템플릿 복사 하기

위의 유의사항을 잘 읽어 봅니다. 꼭이요. 그래서 일부러 복사 하는 법을 더 아래에 놓습니다.
위의 링크를 눌러 주간 업무 노션 페이지로 들어갑니다.
우측 상단의 '복제' 버튼을 누르면 자동으로 복사 됩니다.
가저가 셔서 편집한 이후, 사용하시면 됩니다! 복제, 복사 등등 마음대로 요리해서 사용하셔도 됩니다.
혹시나, 상업적인 이용은 불가능합니다. (될 것 같지도 않습니다...)
질문은 댓글로... 고맙다는 인사는 마 고마, 됐심더...!

2023.06.19(Mon.) <React 모바일 웹 환경에서 키패드 처리>

HyeonSi — Mon, 19 Jun 2023 21:52:24 +0900

키패드는 죄가 없는걸요

1. 문제의 발단

chatGPT의 도입으로, 서비스에 대화형 인공지능 기능을 개발했다.
개발은 그리 어렵지 않았다.(사실 백엔드 처리가 주요 이슈였기 때문에 에러 응답 처리 및 로딩 애니메이션, 유저 인터렉션, 컴포넌트 구현중 레이아웃 흐트러짐등 정도만 하면 되는 일이었다.)
하지만 생각지도 못 한 복병이 있었다. 모바일 환경에서 대화를 위한 모바일 키패드가 화면을 절반 이상 가려버렸다.

2. 환경 세팅

먼저, 개발 환경의 PC 상황에서는 키패드를 열 수 조차 없었다.
하지만 검색결과 Nexus5, Nexus5X 기기에서는 완벽하진 않아도 적당히 열 수 있는 방법이 있다고 했다.

'크기' 옆의 기기 종류를 눌러 추가 시켜주고, 가장 오른쪽의 기기 회전 아이콘에서 키보드로 바꿔주면 된다.

이렇게 다 열린다. 물론 보이는 화면은 매우 작다.

3. 어떻게 처리 할 것인가?

내용이 들어갈 공간을 window.innerHeight로 잡고 스크롤을 만들어 준다.

import React, { useState } from 'react';

const Container = () => {
	// state로 innerHeight를 잡아 줬다.
	const [innerHeight, setInnerHeight] = useState(0);
    
    // innerHeight가 바뀔경우 다시 계산한다.
    useEffect(() => {
    	setInnerHeight(window.innerHeight);
  	}, [window.innerHeight]);
	
    // 위 헤더나, 푸터가 있을경우 innerHeight - 여분의 사이즈로 맞출 수 도 있다.
    return (
    	<div className={tw`h-[${window.innerHeight}px]`}>
        	<div className={tw`h-[${innerHeight}px])`}>뭔가 굉장히 길어질 수 있는 컨텐츠</div>
        </div>
    )
}

4. 여담

위의 코드는 예시일 뿐이라 리소스 낭비가 심하다. useEffect에 timeout으로 유저의 동작이 멈췄을 경우만 innerHeight를 계산하는 방식이 옳을 것이다.
useMemo를 이용하는 방법도 생각해 봤는데, 스크롤은 변화가 심해서 더 낭비일 것이다.
프로젝트 초기 세팅이 twind라서 그 기반으로 예시 코드를 작성했다. 해석에는 문제가 없을 것이다. (사실 질문 환영)
확실한 것은 다 구현이후, 올바르게 동작하는 것은 확인했지만, 처음부터 모바일 구성이 기획에 없었어서 급하게 사이즈만 줄여 넣자 라고 아쉽게 구현되었다. 처음에는 상단 헤더 또한 큰 사이즈를 차지해 곤란한 상황. 부랴부랴 맞춰 넣은 감이 없지 않다.