개발하는 음대생

transform 애니메이션이 성능이 더 좋은 이유

JWOOKJ — Thu, 4 Jul 2024 18:42:00 +0900

브라우저의 렌더링 과정
2021.06.04 - [개발/WEB] - TIL #28 브라우저는 어떻게 작동하는가

TIL #28 브라우저는 어떻게 작동하는가

나는 개발을 할 때, 내가 개발하고 있는 서비스를 폭넓게 이해한 상태에서 실사용자의 입장을 생각하며 개발을 하는 사람이 좋은 개발자라고 생각한다. 개발을 공부하며 내가 무언가 만들 수 있

jwookj.tistory.com

먼저 브라우저의 렌더링은 간단하게 style - layout - paint- composite의 단계로 나눠지게 되는데,

style의 단계에서 HTML을 통한 DOM트리 생성, CSS를 통한 CSSOM트리 생성과 Javascript 엔진에 의한 javascript 코드 해석이 일어나게 되고 해당 결과물들을 통해 render tree를 만들게 됩니다.

layout 단계에서는 reder tree를 기반으로 tree의 각 노드들의 크기와 위치를 계산하게 됩니다.

paint의 단계에서는 노드를 실제로 화면에 그리는 작업이 일어나게 되는데 이때 특정 htm태그(video, canvas)와 css속성(opacity, transform, will-change 등...)에 따라 GPU에게 일임하는 그래픽 레이어를 별도로 생성하게 됩니다.

composite의 단계는 그려진 paint의 레이어를 합치는 작업을 하게 됩니다.

transform 애니메이션의 장점

reflow : 생성된 DOM 노드의 레이아웃(너비, 높이 등) 변경 시 영향받는 모든 노드(자식, 부모)의 수치를 다시 계산하여 렌더 트리를 재생성하는 작업입니다.

CSS의 transform 속성은 CPU가 아닌 GPU에서 처리됩니다.

GPU는 반복되는 작업의 병렬처리에 최적화되어있는 장치이고 CPU의 메인 쓰레드와는 별개로 작동합니다.
이러한 특징 때문에 transform 속성을 사용해 애니메이션을 구현할 경우 CPU의 부하를 덜고 더 나은 하드웨어의 성능을 기대할 수 있게 됩니다.

transform 속성은 애니메이션이 일어날 경우 위에서 언급한 paint 단계에서 그래픽 레이어로 구분되기 때문에 reflow가 일어나지 않게 되고 이후 composite 단계의 작업만 발생하게 되기 때문에 훨씬 효율적인 렌더링이 가능해집니다.

참고

https://mong-blog.tistory.com/entry/CSS-%EC%99%9C-transform-%EC%95%A0%EB%8B%88%EB%A9%94%EC%9D%B4%EC%85%98-%EC%84%B1%EB%8A%A5%EC%9D%B4-%EC%A2%8B%EC%9D%84%EA%B9%8C-with-GPU-Reflow

[CSS] 왜 transform 애니메이션 성능이 좋을까? (with. GPU, Reflow)

1. Left 애니메이션은 왜 끊길까? transform, left 속성으로, 대각선 방향으로 움직이는 공 애니메이션을 만들어봤다. See the Pen Animate with Translate and left by KumJungMin (@kumjungmin) on CodePen. 보기에는 둘 다 잘

mong-blog.tistory.com

https://ssocoit.tistory.com/258

[CSS] Blink엔진에서 transform 속성은 Reflow와 Repaint가 발생하지 않는다

Reflow와 Repaint에 대해서 너무 겉핥기로만 알고있는게 아닐까.. 고민하게 만들어준 문제입니다. 단순히 어떤 동작이 발생하는지만 파악하고 넘어가는 것보다는 사용하는 CSS 속성에 따라 어떻게

ssocoit.tistory.com

베스트 앨범

JWOOKJ — Wed, 12 Jun 2024 15:29:42 +0900

기존에 풀이했던 프로그래머스의 베스트 앨범의 개선 코드입니다.

2022.02.07 - [코딩테스트/Javascript] - 베스트 앨범

베스트 앨범

#문제 스트리밍 사이트에서 장르 별로 가장 많이 재생된 노래를 두 개씩 모아 베스트 앨범을 출시하려 합니다. 노래는 고유 번호로 구분하며, 노래를 수록하는 기준은 다음과 같습니다. 속한 노

jwookj.tistory.com

#풀이

const solution = (genres, plays) => {
  const genreMap = new Map();

  genres.map((genre, index) => [genre, plays[index]]).forEach(([genre, play], index) => {
    const musicData = genreMap.get(genre) || { total: 0, songs: [] }
    genreMap.set(genre, {
      total: musicData.total + play,
      songs: [...musicData.songs, { play, index }]
        .sort((a, b) => b.play - a.play)
        .slice(0, 2)
    })
  })

  return [...genreMap.entries()].
    sort((a, b) => b[1].total - a[1].total).
    flatMap(genre => genre[1].songs).
    map(song => song.index);
}

flatMap 메서드는 반환하는 요소에 대해 한단계 평탄화를 적용한 배열을 반환합니다.

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMap

Array.prototype.flatMap() - JavaScript | MDN

Array 인스턴스의 flatMap() 메서드는 배열의 각 요소에 주어진 콜백 함수를 적용한 다음 그 결과를 한 단계씩 평탄화하여 형성된 새 배열을 반환합니다. 이 메서드는 map() 뒤에 깊이 1의 flat()을 붙이

developer.mozilla.org

react에서 Next.js v14로 마이그레이션 하기

JWOOKJ — Wed, 8 May 2024 12:13:15 +0900

tl;dr

StudyFront(구 Hypen) 프론트엔드 스택을 react +typescript + vite에서 Next.js v14로 변경했습니다.
많관부~

배경

현재 재직중인 회사에서 서비스 중인 StudyFront에서는 사용자들끼리 입시에 관한 고민상담, 정보 공유를 위한 커뮤니티 서비스를 최근 새로 오픈했습니다.
커뮤니티 서비스를 오픈한 이유는 여러가지가 있었지만, 그 중 큰 비중을 차지한 한가지는 ‘신규 사용자의 유입’이었습니다.
이를 위해서는 **각 게시글에 대한 SEO(Search Engine Optimization)**가 이루어지는 것이 첫번째 관문이라고 생각되었습니다.

문제

초기 StudyFront(구 Hypen)는 개발단에서 빠른 속도와 테스트, 업데이트가 필요했고, 이를 위해 개발자의 숙련도(개발 속도), 초기 개발 환경 구성의 용이함에 초점을 맞춰 react + typescript + vite를 활용한 프로젝트로 구성되어 있었습니다.
해당 스택의 문제점은 커뮤니티 서비스가 새로 오픈하고 각 게시글 페이지 별로 메타태그를 적용해야하는 상황에서 부각되었습니다.
react는 기본적으로 **CSR(Client Side Rendering)**을 지원하는 SPA(Single Page Application) 라이브러리이고, CSR을 지원하는 SPA 라이브러리에서는 단 하나의 HTML 파일만을 사용하여 웹페이지를 렌더링하기 때문에 각 페이지별 SEO를 위한 메타태그를 적용하기 어려운 상황이었습니다.

SPA(Single Page Application) : 기존의 웹페이지는 각 페이지마다 서버에서 HTML을 생성하여 클라이언트로 전달해주는 MPA(Multiple Page Application) 방식 이었습니다.

해당 방식은 UX측면, 서버의 부하등의 단점이 존재했는데, 이를 해결하기 위해 프로젝트 내에 단 하나의 HTML파일을 두고 페이지 이동 시, 해당 HTML 파일 내에서 Javascript를 활용하여 동적으로 페이지를 렌더링 하는 SPA 방식이 등장하게 되었습니다.

흔히 프론트엔드 프레임워크 3대장(react, vue, angular)이라고 불리는 프레임워크들이 해당 방식을 채택하고 있습니다.

해결 방안

해당 문제를 해결하기 위해 3가지의 선택지를 고려했습니다.

react-snap + react-helmet을 활용한 정적 페이지 + 동적 메타태그 적용
server-side-rendering을 위한 자체 서버 구축
react => Next.js로의 마이그레이션

Next.js는 react를 위한 프레임워크입니다. react에서 제공하지 않는 기능, 혹은 사용하기 복잡한 기능의 사용을 용이하게 도와줍니다. (ex. server-side-rendering, etc…)

1. react-snap + react-helmet을 활용한 정적 페이지 + 동적 메타태그 적용

react-snap 라이브러리는 업데이트 된지 5-6년 되었고, 동적 라우팅에 대해 제대로 대응하지 못한다는 문제점과 react-helmet 라이브러리는 동적으로 생성된 메타태그가 제대로 구글 크롤러봇에 의해 수집되지 못한다는 이슈가 있었기에 선택에서 제외했습니다.

react-snap : 프로젝트 빌드시에 모든 경로의 페이지를 정적 HTML 파일로 빌드해주는 라이브러리입니다.
react-helmet : 동적으로 HTML head 태그 내에 메타태그를 삽입할 수 있게 해주는 라이브러리입니다.

2. server-side-rendering을 위한 자체 서버 구축

작성하신 글을 읽을 때마다 감탄하게 되는 Evan Moon님의 Vue Server Side Rendering 글을 보고 자체적으로 server side rendering 서버를 구축하는 것이 오히려 개발 기간을 단축시킬 수 있지 않을까 고민했습니다.

하지만 서버 구축 이후의 배포 과정, 적용 후 발생할 side effect와 이후의 확장성을 고려했을 때 해당 목적만을 지닌 서버를 구축하기 보다는 범용적으로 사용되고 있는 프레임워크의 힘을 빌리는 것이 조금 더 서비스를 위한 방법이라고 생각되었습니다.

3. react => Next.js로의 마이그레이션

최종적으로 Next.js로 마이그레이션 하는 작업이 가장 안정적이고 빠르게 문제를 해결할 수 있다고 생각되었습니다.

Next.js를 알기 전에 알아야 할 지식

마이그레이션 과정을 설명하기 전에 Next.js를 사용하기 위해 알고 있으면 좋을 지식들을 먼저 간략하게 정리합니다.

렌더링(Rendering) : 웹 프론트엔드 개발에서 렌더링은 코드가 렌더링 엔진(Blink, Gecko, Webkit)에 의해 브라우저에 그려지는 과정을 이야기기합니다.
크게 DOM 트리, CSSOM 트리 생성 → 렌더링 트리 생성 → 레이아웃 → 페인팅의 단계로 이루어집니다.

CSR(Client Side Rendering)

CSR은 말 그대로 클라이언트 측에서 모든 렌더링을 진행하는 것입니다.
서버측에서는 초기에 SPA의 기본 뼈대가 되는 skeleton HTML(index.HTML)을 전달해 준 뒤에 Javascript 파일을 전송합니다.
클라이언트는 초기 HTML의 DOM트리를 생성한 후에 Javascript 코드 요청을 보내고 받아온 Javascript 코드의 내용에 따라 기존 DOM트리를 확장하여 동적으로 DOM트리를 생성, 조작하게 됩니다.
react는 이 과정에서의 DOM트리 조작 최적화를 위해 Virtual DOM을 활용합니다.

SSR(Server Side Rendering)

SSR은 서버 측에서 먼저 페이지에 보여질 HTML을 생성한 후에 클라이언트에게 완성된 HTML을 전달합니다.
클라이언트는 완성된 HTML을 통해 DOM트리를 생성하게 되고, 사용자와의 상호작용(ex. click, focus, etc…)을 위해 Javascript 코드를 받아와 hydrate의 과정을 통해 HTML에 Javascript 로직을 주입하는 거치게 됩니다.

Server Component

React Server Component(RSC)는 Meta의 react 팀에서 새로 도입한 기술입니다.
Dan Abramov(전 Meta react 팀, redux 창시자)에 의해 2020년에 처음으로 발표 후 react v18에서의 실험적 기능을 거쳐 Next.js v13의 app router 방식에 사용 되었습니다. (개인적으로 좋아하는 Dan의 글도 첨부합니다.)

Component?

컴포넌트(component) : 리액트에서 사용되는 독립된 블럭 단위의 재사용 가능한 ui 코드를 뜻합니다.

기존 리액트의 컴포넌트는 모두 클라이언트에서 생성되는 컴포넌트였습니다. 서버와의 통신은 데이터를 갱신할 때만 이루어 졌고, 갱신된 데이터에 따라 컴포넌트는 동적으로 ui를 생성했습니다.

즉 기존 컴포넌트는 서버의 자원에 직접적으로 접근할 수 없었고, 서버에서 허용된 정보만을 요청을 통해 받아올 수 있었습니다.

react는 서버 컴포넌트를 통해 기존 컴포넌트가 갖고 있던 불편함을 해소할 수 있는 방법을 제시했습니다.

서버 컴포넌트는 서버에서 생성되는 컴포넌트입니다.
위의 SSR과 조금 헷갈릴 수 있지만 가장 큰 차이는 SSR은 string HTML을 반환하게 되고, 서버 컴포넌트는 RSC(React Server Component)를 payload 형태로 반환한다는 점입니다.

Server Component의 특징

서버에서 생성되기 때문에 서버 자원(파일 시스템, DB, etc…)에 직접적으로 접근할 수 있습니다.
이미 서버에서 생성된 컴포넌트를 받기 때문에 컴포넌트를 구성하기 위한 추가적인 Javascript 코드의 양을 줄일 수 있게 됩니다.
서버에서 랜더링 되기 때문에 랜더링에 필요한 데이터를 가져오는 시간과 클라이언트가 요청하는 횟수를 줄여서 성능 향상에 도움을 줄 수 있습니다.
서버에서 생성되고 관리되기 때문에 기존 component의 life cycle을 관리하는 hook( useState, useEffect)과 커스텀 hook을 사용하지 못합니다.
마찬가지로 서버에서 생성되기 때문에 브라우저에서 접근 가능한 window api에 접근하지 못합니다.
DOM을 통해 사용자와 상호작용할 수 있는 Event Listener를 사용하지 못합니다.
현재 React Server Component는 함수형 component만을 지원하기에 class형 component는 사용할 수 없습니다.

Next.js v13

Next의 최신 버전은 14이고 현재 StudyFront에서도 14버전을 사용하고 있지만 대대적인 변화가 생긴 버전은 13이기에 13버전의 변화를 중점으로 정리하겠습니다.

Next.js는 react를 위한 프레임워크입니다. 이전 Next.js v12에 대한 내용은 여기에 정리해 놓았습니다.
react에서 server component를 공개한 후 Next에서도 server component를 활용한 새로운 아키텍처와 기능을 추가하였습니다.

app router

기존 Next.js는 pages router 방식을 사용하여 page 폴더 내에 배치한 폴더 구조에 따라 url routing을 지원했습니다.
이후 server component를 좀 더 용이하게 사용하고자 Next.js 에서는 새로 app router방식을 공개했습니다. (pages router 방식을 사용할 수도 있습니다.)

app router를 사용하게 된다면 프로젝트 내 컴포넌트는 기본적으로 서버 컴포넌트를 사용하게 됩니다.
app router 방식에서도 app 디렉토리 내의 폴더 구조를 통해 라우팅이 되고 각 폴더의 page파일을 해당 경로의 기본 페이지로 인식합니다. (각 폴더 명이 경로명으로 적용됩니다.)

StudyFront 중첩 구조

위의 예시를 보면 폴더명에 따라 url은 www.studyfront.co.kr/calculator 가 되고 해당 주소로 진입했을 때 가장 먼저 보여지는 ui는 page.tsx가 됩니다. (app 디렉토리 내 root 경로의 page.tsx파일은 www.studyfront.co.kr/ 의 초기 ui를 보여주게 됩니다.)

페이지별 중첩 구조

출처 :&nbsp; https://nextjs.org/docs/app/building-your-application/routing

app router 내 각 폴더(url 경로)는 위의 구조를 갖게 됩니다.

layout : 페이지를 이루는 컴포넌트 중 가장 상위의 개념이 됩니다. 페이지에서 공통으로 적용하는 ui를 담을 수 있습니다. 하위 컴포넌트의 상태가 변경되어도 재렌더링 되지 않습니다.
page : 경로에 따른 페이지 고유의 ui를 담을 수 있는 컴포넌트입니다. 페이지에서 보여주어야 하는 핵심 ui를 보여줍니다.
template : layout과 비슷하게 공통으로 적용하는 ui를 담을 수 있지만, 하위 페이지의 상태 변경시 재렌더링이 되어야 하는 ui를 담아야 합니다.
error : 페이지 내 에러 발생시 보여지는 ui를 담고 있습니다.
loading : 페이지 내 로딩 발생시 보여지는 ui를 담고 있습니다.
not-found : 해당 경로에 존재하는 페이지가 없을 경우 보여지는 ui를 담고 있습니다.
global-error : app 디렉토리의 root 경로에만 추가할 수 있는 파일로 전역 에러를 담당하는 ui를 담고 있습니다.

app router에서는 react의 Suspense와 Error boundary를 적극적으로 활용하고 있기 때문에 각 페이지 별로 loading.tsx, error.tsx를 통해 선언적으로 로딩 상태와 에러 상태를 관리해줄 수 있습니다.

HTML Streaming

서버에서 렌더링 되는 페이지의 경우 사용자가 페이지를 이용하기까지 몇가지 필요한 과정들을 거쳐야 합니다.

페이지에서 필요한 데이터 가져오기
서버에서 페이지의 HTML 렌더링하기
페이지의 HTML, CSS, Javascript를 클라이언트로 전달하기
아직 사용자와의 상호작용이 되지 않는 페이지를 HTML, CSS로 보여주기
hydrate 과정을 통해 사용자와의 상호작용이 되도록 적용하기

출처 :&nbsp; https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming

위의 단계들은 순차적이고 다음 단계의 진행을 차단합니다. 또한 react는 Javascript hydration이 일어난 이후에 ui를 표현해 줄 수 있기 때문에, 사용자는 위의 모든 단계가 끝나기 전까지는 빈 페이지를 보게 됩니다.

출처 :&nbsp; https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming

HTML streaming은 서버에서 렌더링 되는 HTML을 좀 더 작은 단위의 chunk로 나누어서 점진적으로 받아올 수 있게 합니다.
이를 통해 사용자는 페이지의 먼저 렌더링 된 부분부터 순차적으로 볼 수 있게 됩니다.

Next.js v12 이상부터 서버에서 렌더링되는 페이지는 자동으로 HTML streaming이 적용됩니다.
HTML streaming과 react Suspense를 활용하여 좀 더 세밀하게 ux를 향상시킬 수도 있습니다.

import { Suspense } from 'react'
import { PostFeed, Weather } from './Components'

export default function Posts() {
  return (
    <section>
      <Suspense fallback={<p>Loading feed...</p>}>
        <PostFeed />
      </Suspense>
      <Suspense fallback={<p>Loading weather...</p>}>
        <Weather />
      </Suspense>
    </section>
  )
}

마이그레이션 적용기

Next.js는 react에서 각 스펙에 따른 마이그레이션 방법을 문서로 제공합니다. StudyFront는 빌드 툴로 vite를 사용하고 있었기에 기본적인 설정은 해당 문서를 참고하여 마이그레이션을 진행하였습니다.

recoil 사용하기

Next.js v13 이후 기본 컴포넌트가 서버 컴포넌트로 적용되기 때문에, 프론트엔드 전역 상태관리를 위한 라이브러리인 recoil을 사용하려면 추가적인 작업을 해주어야 합니다.
recoil을 전역으로 사용해주기 위해 모든 컴포넌트의 상위에 <RecoilRoot> 컴포넌트를 선언해 주어야 하는데 RecoilRoot컴포넌트는 내부적으로 react의 context api를 사용하고 있습니다.
context api는 프론트엔드 측에서 상태관리를 위해서 사용하는 react의 스펙으로, 구독하는 값이 변경될 때마다 구독을 신청한 컴포넌트를 재렌더링 합니다.
이때 서버측에서 렌더링이 진행되는 서버 컴포넌트의 경우 구독하는 값이 변경됨에 따라 컴포넌트를 계속해서 새로 그리게 된다면 서버에 부하를 일으킬 수 있습니다.
또한 react에서 서버 컴포넌트를 만든 이유는 서버측의 데이터를 반영하는데에 중점을 가진 컴포넌트를 만들고자 함이었는기 때문에 프론트엔드 측의 사용자와의 상호작용을 위한 값과는 별도로 관리를 위해 서버 컴포넌트에서는 context api를 사용할 수 없도록 만들었습니다.
그런 이유로 Next.js에서 recoil을 사용하기 위해서는 클라이언트 컴포넌트로 <RecoilRoot>를 감싸주는 과정을 진행해야 합니다.

// Next.js에서 클라이언트 컴포넌트를 사용하기 위해서는 컴포넌트 파일 상단에 해당 문구를 추가해야합니다.
'use client';

import React, { ReactNode } from 'react';
import { RecoilRoot } from 'recoil';

const RecoilWrapper = ({ children }: { children: ReactNode }) => {
  return <RecoilRoot>{children}</RecoilRoot>;
};

export default RecoilWrapper;

이후 app 디렉토리 최상단의 layout.tsx에서 <RecoilWrapper> 컴포넌트로 children 속성을 감싸줍니다.

import React, { ReactNode } from 'react';
import RecoilWrapper from '../RecoilWrapper';

const RootLayout = ({ children }: { children: ReactNode }) => {
  return (
    <html lang="en">
      <body>
        <div id="root">
          <RecoilWrapper>
              <Template>{children}</Template>
          </RecoilWrapper>
        </div>
      </body>
    </html>
  );
};

export default RootLayout;

styled components 사용하기

Next.js 공식문서에서는 styled components를 사용하기 위한 설정을 문서로 제공하고 있습니다.
해당 문서에서는 SSR을 위한 설정까지는 제공하고 있지만 문서 최상단에 해당 경고가 있습니다.

Warning: CSS-in-JS libraries which require runtime JavaScript are not currently supported in Server Components. Using CSS-in-JS with newer React features like Server Components and Streaming requires library authors to support the latest version of React, including concurrent rendering.
We're working with the React team on upstream APIs to handle CSS and JavaScript assets with support for React Server Components and streaming architecture.

경고: 런타임 자바스크립트가 필요한 CSS-in-JS 라이브러리는 현재 서버 컴포넌트에서 지원되지 않습니다. 서버 컴포넌트 및 스트리밍과 같은 최신 React 기능과 함께 CSS-in-JS를 사용하려면 라이브러리 작성자가 동시 렌더링을 포함한 최신 버전의 React를 지원해야 합니다. 저희는 React 서버 컴포넌트 및 스트리밍 아키텍처를 지원하는 CSS 및 JavaScript 에셋을 처리하기 위해 업스트림 API에 대해 React 팀과 협력하고 있습니다.

현재 Next.js에서 Server Component를 사용시 CSS-in-JS 라이브러리는 지원하지 않고 있음을 알 수 있습니다.
해당 이슈를 해결하기 위해서 StudyFront에서는 서버 컴포넌트가 필요한 컴포넌트내의 스타일을 별도의 스타일 파일을 생성 후 기본 css를 적용하여 해결하였습니다.

error handling

Next.js에서는 react의 Error boundary를 활용하여 선언적 방식으로 에러를 처리할 수 있게 합니다.
경로 폴더 내 error 파일을 추가하여 ui 렌더링 시 에러가 발생하면 error ui를 노출하게 됩니다.
만일 해당 경로 폴더에 error 파일이 없다면, 상위 폴더의 error ui를 노출하게 됩니다.
Server Component의 경우 컴포넌트 내에서 발생한 에러는 가장 가까운 error 파일로 전달되게 됩니다.
Error boundary는 렌더링 과정에서의 오류만을 포착하기에 해당 스펙을 사용할 경우 포착할 수 없는 오류들이 몇가지 존재합니다.

이벤트 핸들러 내의 오류
비동기 코드 오류 (Promise, setTimeout, setInterval, async/await, etc…)
Error boundary 자체의 오류
렌더링 이외의 모든 오류…

이러한 부분들 중 비동기 관련 코드는 서버에서 데이터를 받아올 때 필수적으로 사용되기 때문에 StudyFront 프로젝트에서는 컴포넌트 내 state를 사용하여 오류를 error 파일로 전달하고 있습니다.

'use client';

import React, { ReactNode, useEffect, useState } from 'react';
import { useRouter } from 'Next/navigation';
import { useSetRecoilState } from 'recoil';

import { fetchGetUserInfo } from '../../core/fetcher/user';
import { getStorage } from '../../core/util/function';
import { userState } from '../../store/user';

const PrivateTemplate = ({ children }: { children: ReactNode }) => {
  const router = useRouter();
  const setUserInfo = useSetRecoilState(userState);

  // 오류 상태
  const [, setError] = useState(null);

  useEffect(() => {
    if (getStorage('token') === null) {
      router.replace('/?link=login');
    } else {
      (async () => {
        try {
          const result = await fetchGetUserInfo();
          setUserInfo(result);
        } catch (error: any) {

        // setError를 통해 오류를 던지는 함수를 곧바로 실행
          setError(() => {
            throw error;
          });
        }
      })();
    }
  }, []);

  return <>{children}</>;
};

export default PrivateTemplate;

react-router-dom → next/navigation

react-router-dom은 react에서 라우팅을 적용하기 위한 라이브러리입니다.
react 프로젝트에서는 클라이언트 측 라우팅을 위해 모든 페이지를 연결하는 route를 선언하고 실행할 수 있게 합니다. 즉 해당 route를 통해 url 경로에 따라 서로 다른 컴포넌트를 노출하도록 설정할 수 있습니다.

// 예시 코드이기 때문에 별도의 import 코드는 추가하지 않았습니다.

const Router = () => {
  const isLogin = useRecoilValue(loginState);

  const router = createBrowserRouter([
    {
      // url path에 따라 다른 컴포넌트를 노출하도록 설정해 줍니다.
      path: '/',
      element: (
        <ErrorBoundary FallbackComponent={ErrorComponent}>
          <Template>
            <NewHome />
          </Template>
        </ErrorBoundary>
      ),
    },
    {
      path: '/mypage',
      element: isLogin ? (
        <ErrorBoundary FallbackComponent={ErrorComponent}>
          <Suspense fallback={<Loading />}>
            <Template>
              <MyPageTemplate />
            </Template>
          </Suspense>
        </ErrorBoundary>
      ) : (
        <Navigate to="/" />
      ),
      children: [
        {
          path: 'my',
          element: <MyInfo />,
        },
        {
          path: 'life_record',
          element: <LifeRecordHistory />,
        },
        {
          path: 'result',
          element: <MyPageResultTemplate />,
          children: [
            {
              path: 'early',
              element: <EarlyResultHistory />,
            },
            {
              path: 'regular',
              element: <RegularResultHistory />,
            },
          ],
        },
        {
          path: 'purchase',
          element: <PurchaseHistory />,
        },
      ],
    },
    {
      path: '/calculator',
      element: (
        <Suspense fallback={<Loading />}>
          <Template>
            <Calculator />
          </Template>
        </Suspense>
      ),
    },
    {
      path: '*',
      element: <Navigate to="/" />,
    },
  ]);

  return <RouterProvider router={router} />;
};

export default Router;

하지만 Next.js는 내부적으로 폴더 구조 기반의 라우팅을 제공하고 있기 때문에 해당 react-router-dom을 사용할 필요가 없습니다.

문제

react-router-dom 라이브러리에는 페이지간 이동(navigating & linking)에 필요한 여러가지 hook을 제공하고 있습니다.
react-router-dom의 대표적인 hook

useNavigate : 현재 페이지에서 다른 페이지로 이동하는 기능을 제공합니다. (window.history api를 사용하여 경로간 정보(state)를 전달할 수도 있습니다.)
useLocation : 현재 페이지에서 가지고 있는 정보(현재 경로의 이름, 이전 경로에서 전달해준 정보(state), etc…)들에 접근할 수 있는 기능을 제공합니다.
useParams : 동적 라우팅에 사용되는 path parameter 값을 가져올 수 있는 기능을 제공합니다.
useSearchParams : query parameter 값을 key / value형식으로 가져올 수 있는 기능을 제공합니다.

react-router-dom을 사용하지 않게 되면서 Next에서는 navigating과 linking을 구현하기 위해 next/navigation ****패키지를 사용하게 되었습니다.
이때 react-router-dom에서 제공하는 hook도 사용을 못하기에 프로젝트 전반에 있는 navigating & linking에 관련된 모든 hook들을 next/navigation에서 제공하는 hook으로 교체하는 작업을 진행했습니다.

https://github.com/vercel/next.js/discussions/48426
현재 Next.js에는 navigating & linking을 적용하기 위한 패키지가 두가지 존재합니다.

next/router : Next.js 13버전 이전에 사용되던 패키지로 가볍고 적은 기능을 가지고 있습니다. app router 방식에는 사용할 수 없습니다.

next/navigation : Next.js 13버전 이후에 개발된 패키지로 next/router와 비교하여 더 많은 기능을 가지고 있고 modern Next.js 프로젝트에 권장됩니다.

next/navigation의 대표적인 hook

useRouter : 페이지 이동, 페이지 새로고침 등 경로와 관련된 기능을 제공합니다.
useParams : 동적 라우팅에 사용되는 path parameter 값을 가져올 수 있는 기능을 제공합니다.
userSearchParams : get 메서드를 통해 query parameter 값의 key를 인자로 받아 value 값을 가져오는 기능을 제공합니다.
usePathname : 현재 페이지의 경로를 가져오는 기능을 제공합니다.

하지만 교체하는 과정에서 문제가 생겼습니다.

기존 useNavigate hook은 state 매개변수를 통해 현재 경로에서 이동하려는 경로로 데이터를 전달할 수 있었습니다. 하지만 next/navigation의 useRouter hook은 해당 기능을 제공하지 않고 있었습니다. (개인적인 추측으로는 SSR 방식과 CSR 방식의 컴포넌트를 혼합하여 사용할 수 있는 Next.js의 특성과 클라이언트 측의 보안과 성능을 이유로 해당 기능을 제공하지 않는 것으로 생각됩니다.)

그런 이유로 기존에 페이지를 이동하며 전달해 주었던 정보를 다른 방식으로 이동한 페이지에서 접근할 수 있도록 수정해 주어야 했습니다.

해결

StudyFront에서는 해당 문제를 sessionStorage에 정보를 저장하는 방식과 url query parameter로 전달하는 방식을 데이터의 특성에 따라 적절히 사용하는 방식으로 해결하였습니다.

Metadata

Next.js로 마이그레이션을 진행한 가장 주된 이유입니다.
Next.js에서는 Metadata를 적용할 수 있도록 컨벤션을 제공하고 있습니다.
메타데이터는 서버에서 생성되는 컴포넌트에 적용할 수 있기 때문에, 적용 전에 Server Component와 Client Component를 섞어서 사용하는 기본적인 패턴에 대해 알아야 합니다.

Server Component 내부에서 Client Component를 import하여 사용하는 것은 가능합니다.
Client Component 내부에서 Server Component를 import하여 사용하는것은 불가능합니다. => 사용하기 위해서는 Server Component를 Client Component의 props로 전달하여 사용해야 합니다.

이러한 패턴을 토대로 각 페이지의 Layout.tsx을 Server Component로 선언함과 동시에 Metadata를 생성해 주었습니다.

// StudyFront 메인 페이지

import React, { ReactNode } from 'react';
import type { Metadata } from 'next';

import Template from '../components/_d_template/Template';
import RecoilWrapper from '../RecoilWrapper';
import GlobalStyle from '../style/GlobalStyle';
import StyledComponentsRegistry from '../style/registry';

export const metadata: Metadata = {
  title: '스터디프론트',
  description:
    '내가 갈 대학 예측을 AI와. 생기부 1인자가 되고 싶다면 스터디프론트에서',
  keywords: [
    '스터디프론트',
    'studyfront',
    '생기부',
    '생활기록부',
    '글자수 세기',
    '입시',
    '입시캐스트',
    '정시 예측',
    '수시 예측',
    '모의고사',
    '입시 커뮤니티',
    '입시 정보',
    '컨설팅',
    '의대',
  ],
  openGraph: {
    title: '입시의 최전선 | 스터디프론트 STUDYFRONT',
    description:
      '내가 갈 대학 예측을 AI와. 생기부 1인자가 되고 싶다면 스터디프론트에서',
    siteName: '입시의 최전선 | 스터디프론트 STUDYFRONT',
    url: '<https://www.studyfront.co.kr>',
    type: 'website',
    images: [
      {
        url: '<https://www.studyfront.co.kr/assets/opengraph_img.png>',
      },
    ],
  },
  alternates: {
    canonical: '<https://www.studyfront.co.kr/>',
  },
};

const RootLayout = ({ children }: { children: ReactNode }) => {
  return (
    <html lang="en">
      <body>
        <div id="root">
          <GlobalStyle />
          <RecoilWrapper>
            <StyledComponentsRegistry>
              <Template>{children}</Template>
            </StyledComponentsRegistry>
          </RecoilWrapper>
        </div>
      </body>
    </html>
  );
};

export default RootLayout;

페이지 경로를 동적으로 받아오는 경우 generateMetadata 메서드를 사용하여 동적으로 Metadata를 생성해 줄 수 있습니다.

// 커뮤니티의 입시의 모든 것 개별 게시글 페이지

import React, { ReactNode } from 'react';
import { Metadata } from 'next';

export const generateMetadata = async ({
  params,
}: {
  // url 경로의 path parameter를 통해 게시글의 id를 가져옵니다.
  params: { post_id: string };
}): Promise<Metadata> => {
  const postId = params.post_id;

  // path parameter를 통해 받아온 id를 사용하여 서버에서 해당 게시글의 정보를 불러옵니다.
  const result = await fetch(
    `${process.env.NEXT_PUBLIC_API_URL}/board/goal/${postId}`,
    {
      headers: {
        'Content-type': 'application/json',
      },
    },
  ).then((res) => res.json());

  const post = result.result[0];

  // 불러온 게시글을 바탕으로 메타데이터를 정의해 줍니다.
  return {
    title: ` ${post.title} | 스터디프론트 입시의 모든 것`,
    description: `${post.content}`,
    keywords: [
      '고등학교 추천',
      '학원 추천',
      '대학 입시 고민',
      '생기부 수정',
      '입시변화',
      '입결',
      '의대 공대 진로고민',
      '입시의 모든 것',
      `${post.title}`,
    ],
    openGraph: {
      title: `${post.title} | 스터디프론트 입시의 모든 것`,
      description: `${post.content}`,
      siteName: '입시의 모든 것 | 스터디프론트 커뮤니티',
      images: ['https://www.studyfront.co.kr/assets/opengraph_img.png'],
      url: `https://www.studyfront.co.kr/community/goal/detail/${postId}`,
      type: 'website',
    },
    alternates: {
      canonical: `https://www.studyfront.co.kr/community/goal/detail/${postId}`,
    },
  };
};

const GoalDetailLayout = ({ children }: { children: ReactNode }) => {
  return <>{children}</>;
};

export default GoalDetailLayout;

위의 과정들을 통해 다행히 큰 이슈 없이 StudyFront의 Next.js 마이그레이션을 완료했습니다.

Next.js는 업데이트 주기가 빠르고 새로운 기술들을 적극적으로 적용하는 프레임워크입니다.
현재 웹 개발의 여러 부분에서 가장 선두적인 행보를 보이는 Vercel이 개발을 주도하고 있기에, 앞으로도 웹 개발 시장을 한동안 주도할 것으로 생각됩니다.

react에서 Next.js로 변경하는 과정에서 성가신 부분도 있었고 막막한 부분도 있었지만, 적용하고 나니 프로젝트가 조금 정돈된 부분을 느끼면서 프레임워크의 장점을 조금 체감하게 되었습니다.
동시에 프레임워크의 편리한 부분들의 이면에 감춰진 적용된 기술들을 알기 위해 노력하는 것도 프레임워크를 잘 사용하기 위해서는 필요한 과정이라고 생각되었습니다.

출처

Next.js 14 변경점

Next.js 14 업데이트 살펴보기 | 요즘IT

지난 10월 26일, Next.js 14가 발표되었습니다. 13 버전 업데이트의 변화가 워낙 커서 그런지 이번에는 상대적으로 변경 사항이 적게 느껴지기도 했습니다. 이번 업데이트에서는 13 버전에서 소개된 A

yozm.wishket.com

Next.js 14

Next.js 14 includes included performance, stability for Server Actions, a new course teaching the App Router, and more.

nextjs.org

Server Component

React Server Components

JavaScript번들에 포함되지 않고 SSR을 보완하는 중간 추상화 렌더링 - zero-bundle-size React Server Components 서버 드리븐 멘탈 모델을 통한 모던 UX를 구현하는데 초점이 맞추져 있으며 현재 React…

patterns-dev-kr.github.io

React 18: 리액트 서버 컴포넌트 준비하기 | 카카오페이 기술 블로그

공식 릴리즈 전인 리액트 서버 컴포넌트에 대해 알아보고 준비해 봅니다.

tech.kakaopay.com

Rendering: Server Components | Next.js

Learn how you can use React Server Components to render parts of your application on the server.

nextjs.org

렌더링

https://yozm.wishket.com/magazine/detail/646/

웹 브라우저의 렌더링이란? | 요즘IT

우리가 인식하지 못할 뿐, 웹페이지는 미리 만들어진 것을 가져오는 게 아니라 실시간으로 그려지는 것에 가깝습니다. 실시간으로 웹사이트가 그려지는 과정, 이 과정을 웹 브라우저의 렌더링

yozm.wishket.com

Input type=number에서 알파벳 e와 연산기호가 입력된다...?!

JWOOKJ — Fri, 22 Mar 2024 14:19:54 +0900

발견한 moment!

현재 개발 중인 서비스에서는 입시 결과를 예측하기 위해 사용자의 과목 점수를 input으로 입력받고 있습니다.

입력될 값은 점수일 뿐이라고 생각해서 input 태그의 type 속성을 number로 지정하고 테스트를 하는 와중에 알파벳 e와 -, + 부호가 입력되는 현상을 발견했습니다...!

왜 그런건지에 대해 조금 서칭을 해보니 input type=number의 경우 '부동소수점'의 표현을 위해 알파벳 e 혹은 E가 입력될 수 있도록 html spec으로 지정되어 있음을 확인했습니다.

(한국어 'ㄷ'도 입력이 됩니다. 키보드 keycode를 통해 입력 받을지에 대한 유무를 판별하고 있는 듯 합니다.)

부동소수점에서 e의 의미

매우 큰 수를 부동소수점으로 표현할 때 e를 사용하게 되는데, e 뒤에 오는 숫자는 10의 지수를 뜻합니다.

지수가 양수이면 소수점을 지수만큼(e 뒤의 숫자) 오른쪽으로 이동시키고 음수라면 왼쪽으로 이동시키면 부동소수점(e)을 사용하지 않았을 경우의 원래 값을 알 수 있습니다.

예시)
12e2 = 12 X 10² = 1200
1443e-3 = 1443 X 1/10³ = 1.443

해결하려면...?

input태그를 사용하며 이러한 현상을 해결하려면 type속성을 text로 설정한 후에 이벤트 핸들러 내에서 정규식 혹은 키보드의 keycode를 통해 숫자만 입력되도록 처리해야 될 것 같습니다.

혹시나 type="number"속성을 사용할 경우 이러한 예외상황을 꼭 고려하여 사용하시길 바랍니다!

참고

https://stackoverflow.com/questions/31706611/why-does-the-html-input-with-type-number-allow-the-letter-e-to-be-entered-in

Why does the HTML input with type "number" allow the letter 'e' to be entered in the field?

I have the following HTML5 input element: <input type="number"> Why does this input allow for the character 'e' to be entered in the input field? No other alphabet character is abl...

stackoverflow.com

https://hianna.tistory.com/413

[Javascript] input 박스에 숫자만 입력되도록 설정하는 4가지 방법

input 박스에서 사용자에게 숫자만 입력되도록 설정하는 방법 4가지를 소개합니다. input 박스에 숫자만 입력되도록 설정하는 4가지 방법 1. 'type'을 'number'로 지정하기 2. 입력된 keycode 체크하기 3. on

hianna.tistory.com

2022년 회고록

JWOOKJ — Sun, 29 Jan 2023 22:26:43 +0900

좀 늦은 2022년 회고입니다.
부트캠프에서 공부하던 시간이 벌써 2년이 되었고 개발자로 일한지도 벌써 1년 반정도가 되었네요
그리고 2021년의 회고를 적고 2021년 3월 이후는 글을 적지 않았습니다.

글을 쓰기 싫었다거나, 딱히 이유가 있어서 그런건 아니고 육아와 일을 병행하다보니 저도 모르게 번아웃이 왔나 봅니다.
결과적으로는 2021년 회고 때 적었던 3가지를 하나도 지키지 못한 해였습니다. ( 반성하자 진짜로....)

2022.01.02 - [개발/끄적끄적] - 2021년 회고록

2021년 회고록

매년 그렇지만 2021년도 참 많은 일들이 지나갔다. 먼저 개발자로서 커리어를 시작했다는 점이 인생에 있어서 큰 터닝포인트가 되지 않았나 싶다. 태어나서 처음 다녀보는 직장이었고, 어리숙한

jwookj.tistory.com

1. 블로그 정리

프론트 개발자라면 블로그 정도는 직접 만들어서 관리해야지! 라는 당찬 포부는 깃헙에 외롭게 남아있습니다....
집에 오면 아이와 놀아주고, 그 후에는 무지성으로 쉬고 싶다는 생각만이 들어서 꾸준히 이어나가지 못했던 부분입니다.
그래도 중간중간 제가 구상한 부분에 대한 테스트는 해왔기 때문에 기술 스택과 첫 화면은 구현이 된 상태입니다.(Next.js , Notion API)
(다만 최근 obsidian이라는 굉장히 탐나는 메모툴을 알게되어서 notion대신 obsidian의 사용을 고민중입니다. )
https://obsidian.md/

Obsidian

Obsidian: A knowledge base that works on local Markdown files.

obsidian.md

올해 3월이 되기 전까지는 프로토타입 정도라도 제 블로그를 만들어서 배포해볼 계획입니다!
(이번에는 부디 이루어지게 도와주세요...! 개발신님...! )

2. 운동

이 또한 제대로 지키지 못한 부분입니다.
하반기 이전에는 '가끔' 아침에 조깅을 하고 퇴근 후에는 집에서 간단한 맨몸 운동은 '조금씩' 했었지만 9월 회사 워크숍에서 발을 조금 다친 후에는 거의 운동을 못하다시피 했습니다.
그러다보니 몸이 운동을 안하는 환경에 익숙해졌고 결과적으로는 크게 불편하지 않습니다....? ‍♂️

해야지...해야지...

하지만 이렇게 살다가는 언젠가는 분명 건강을 소홀히 한 댓가(?)를 분명히 받게 될 것 같았습니다.
그래서 PT를 받기로 했고 집앞 헬스장에 등록 했습니다.
오랜만에 방문하는 헬스장이라서 조금 어색하지만 빠르게 적응해서 얼른 최상의 컨디션을 유지하는 몸상태로 끌어올리려고 합니다!

ㅠㅠㅠㅠㅠ

3. 커리어

회사에서는 프론트 개발자로서 일을 하고 있고 프론트 생태계에서의 트랜드를 제가 하고 싶은대로 적용해 볼 수 있는 환경이라서 이것저것 많이 프로젝트에 적용해본 한 해였습니다.
아무런 문서와 규칙이 없던 사내 프론트엔드 개발의 개선을 위해,

코드 컨벤션 수립 (협업을 위한 lint, prettier 규칙과 git 컨벤션 포함) => 현재도 필요에 따라 계속 개선중
타입스크립트 도입
yarn berry 도입
Next.js 도입
프로젝트시 새로운 툴, 혹은 라이브러리에 대한 설명 간략하게 문서화하여 공유
프로젝트에서의 이슈사항과 해결과정 문서화하여 공유
성의있는(?) readme..... (제발...)

이러한 부분들을 시도했습니다.
현재는 주로 사용하던 styled-component 대신 tailwind를 적용해보며 장단점을 확인해보고 있습니다.

또한 의도치 않게

부하테스트를 위한 툴 (Jmeter / grasshopper / nGrinder)의 사용법과 결과 해석 방법을 알아보았습니다.
외주 프로젝트의 폐쇄망 작업을 위해 리눅스 centOS 서버에서 npm과 node를 설치할 수 없는 끔찍한 상황을 경험했습니다.... (root 계정이요...?)
시연을 위한 불필요한 프론트 작업

등을 경험했습니다.

마지막 3번의 부분은 실제 사용되는 디자인과 기획된 프로덕트가 아닌, 실제 디자인과 기획이 나오기 전까지 현재 제가 속한 팀이 얼만큼 작업을 했는지를 보고하기 위한, 제가 느끼기엔 굉장히 불필요한 프론트 작업이었습니다.
이러한 부분을 개선하기 위해 어떻게 프로젝트의 진행 방식을 개선해야 할까를 고민해보았지만, 프로젝트가 진행되는 방식 같은 부분은 저 혼자 바꿀 수 있는 것이 아니란 것도 크게 느낀 한 해였습니다.

그리고 이러한 부분들이 제가 앞으로 가져나갈 개발자로서의 커리어를 생각하게 되었습니다.
현재 하고 있는 일을 내가 정말 전문성을 갖고 있다고 말할 수 있을 정도로 잘 하고 있는가?
현재 하고 있는 일을 과연 내가 10년 후에도 잘 할 수 있는가?
현재 하고 있는 일에 대해 나는 얼만큼 만족하는가?
이런 커다란 고민에서부터 파생된 작은 고민들까지 많은 생각을 하고 있습니다.
처음에는 하기 싫은 고민이었지만 아마 커리어 내내 이런 고민들은 끊이지 않을 것 같기도 하고, 이런 고민이 전혀 없는 것도 도태되었다는 신호인것 같아서 계속 고민해보려고 합니다.

현재까지 이러한 고민을 통해서 알게된 부분은

나는 뭔가 큰 그림을 그리거나 설계를 하는 것에서 보람과 재미를 느끼는 사람이다.
한가지 부분에 있어서 꾸준히 깊은 부분까지 파는 장인이 되는 것도 굉장히 어려운 부분이고, 충분히 인생을 걸어볼만한 도전이라고 생각되지만 개인적으로 비단 소프트웨어 뿐만이 아닌 여러 부분에서, 각 상황과 환경에 맞는 전체적인 설계를 이루어냈을 때, 더 큰 성취감을 느끼는 것 같습니다.
이러한 부분을 찾기까지는 XL8의 배휘동님의 글이 많은 도움이 되었습니다.
https://steady-study.super.site/frontend-engineer-career-roadmap
하지만 그런 일을 하기에는 현재 경험과 실력이 부족하다.

입니다.

여기에서의 실력은 제가 맡은 부분(현재 프론트 웹 개발)만이 아닌 전체적인 프로젝트의 구조의 설계와 필요한 비용, 인력, 기간등을 산출하고 적절하게 분배할 수 있는 능력을 염두에 두고 적었습니다.

그리고 결과적으로는 제가 부족한 부분인 경험과 실력을 모두 채우기 위해 일과 학습을 병행할 수 있는 특수대학원에 소프트웨어 전공으로 진학하기로 결정했습니다.
시간은 내면 되고 노력은 하면 되는 것이기에 고민할 필요 없었지만 비용적인 부분에서 많은 고민을 했습니다.
학기마다 등록금이 만만치 않아서 합격발표를 받은 후에도 몇번씩 등록하지 말까라는 고민을 했지만 이후, 더 나은 실력과 더 넓은 시야를 가지고 일을 하는데에 도움이 될 것이라고 생각되어 진학을 결심했습니다.

2022년의 회고는 '2021년의 회고에서 지키지 못한 점을 개선해서 지켜야겠다' 라는 느낌의 회고가 된것 같네요 ㅎㅎ..
2023년에는 꼭 위의 다짐을 잘 지켜서 제가 만든 블로그에서 2023년의 회고를 적도록 해야겠습니다. (제발....)

TIR ##5 [How To Study Design Patterns as a Web Developer]

JWOOKJ — Wed, 30 Mar 2022 06:40:54 +0900

학습을 목적으로 Medium에서 읽은 글을 번역한 글입니다.
번역이 완벽하지 않을 수 있고,
직역하기보다는 문맥에 맞추어 자연스럽게 정리하려고 했습니다.
오류나, 개선하면 좋을 부분들에 대한 피드백은 언제나 환영합니다.

How To Study Design Patterns as a Web Developer

몇 년 전 동료와 나는 프론트엔드 개발자 인터뷰 진행 시 개발자를 평가하는 회사의 기준을 수정하는 직무를 받게 되었다.

나는 우리 프로젝트를 위해 코드를 짜본 경험을 바탕으로 지원자와 이야기할 주제들을 목록으로 정리해 놓았다.

우리는(나와 동료) 지원자를 평가하는데에 있어서,

꼭 알아야 하는 중요한 개념은 무엇인지와, 어떠한 부분은 알고 있으면, (혹은 경험해 봤으면) 좋은 부분인지를 결정하는 데에 거의 모든 부분에서 의견이 일치했다.

하지만 특정한 부분에서는 서로의 의견이 맞지 않았다. '디자인 패턴 '

나느 이러한 부분에 대해서 다른 동료들과 이야기하던 중, 커뮤니티 내의 많은 시니어 개발자들이, 숙련된 프론트엔드 개발자의 작업에 디자인 패턴이 중요하다는 것을 믿지 않는다는 것을 알고 놀랐다.

이러한 디자인 패턴은 객체지향 패러다임에만 적용이 가능하고 자바스크립트에는 항상 적용할 수 없다는 생각이 이미 만연해 있었다.

이 글의 목표는 웹개발자로써, 당신이 디자인 패턴을 공부하고 연습하는 데에 자신의 시간을 투자해야 한다는 것을 확신시켜주는 것을 목표로 한다.

이것을 실천하기 위해서는 첫번째로 어떠한 패턴들이 존재하는지와 왜 사람들이 자바스크립트와 같은 언어와 디자인 패턴은 맞지 않다고 생각하는지를 분석해봐야 한다.

그 후 우리는 모든 패턴과 모든 프로그래밍 패러다임을 적용할 수 있는, (예를 들어 chain of responsibility와 같은) 프레임 워크를 제안할 수 있다.

마지막으로, 실제로 이러한 패턴들이 적용된 코드를 통해 어떻게 그들이 당신이 매일 사용하는 서비스의 코드퀄리티를 상승시켰는지 알아볼 것이다.

What a Design Pattern really is

디자인 패턴은 반복되는 소프트웨어 구조의 문제에 대한 간단하고, 유지보수가 용이하고, 높은 재사용성을 제공하는 해결책이다.

이러한 23가지의 패턴은 90년도 초기에 Gang of Four라는 이름의 베스트셀러 책으로 엮어져서 나왔고, 빠르게 널리 채택되어서 소프트웨어 개발 분야의 초석이 되었다.

우리가 알고 있어야 하는 점은, 책은 출판된 지 30년 정도 되었고, 이 당시는 객체지향 기반의 언어에 굉장히 많은 영향을 받고 있었고, 사람들은 객체지향 프로그래밍에 대한 아이디어에 빠져있었다는 것이다.

따라서, 몇몇 패턴들은 자바스크립트와 같은 현대의 스크립트 언어에서는 제대로 된 번역을 제공하지 못하는데, 객체지향 프로그래밍에서 사용되는 몇 가지 개념들이 빠져있기도 했었고, (심지어 지금도) 혹은 많은 언어들이 지금에는 자체적인 패턴 구조를 제공하기도 하기 때문이다.

이러한 점들을 보완하기 위해, 몇몇 패턴들에 대해, 많은 선의의 저자들이 객체지향 프로그래밍의 개념을 자바스크립트로 동일하게 변환하여 웹 개발자들에게 제공하려 한다.

이 글을 읽고 있는 많은 사람들이 class 개념을 매일 사용하는 것이 아니기 때문에 이러한 개념을 배우는 것이 시간낭비라고 생각할 수 있다.

저자와 독자 모두 간과할 수 있는 부분은, 클래스와 객체의 개념은 그저 도구일 뿐이라는 것이다.

반면, 디자인 패턴은 우리가 필수적으로 해야 하는 것에 대한 문제와 해결책을 말해준다.

엔지니어의 일은 도구를 사용하는 것이 아니라, 복잡한 문제에 대한 간단한 해결책을 제공하는 것이다.

도구는 그저 해결책을 표현하는 방식일 뿐이다.

프론트엔드 개발자로서 우리는 다른 소프트웨어 엔지니어보다 클래스나 객체의 개념을 많이 사용하지 않을 수도 있다. 하지만 우리가 직면하는 문제는 결국 프로그래밍적 문제이다.

다행히, 디자인 패턴은 클래스나 객체, 혹은 상속 vs 결합에 관한 것이 아니다.

디자인 패턴은 복잡한 문제와 문제에 대한 간단하고, 확장성있고, 높은 재사용성을 가지는 해결책들의 요약본이며, 우리는 이러한 본질에 집중해야한다.

how to think about patters

패턴을 공부하는 가장 좋은 방법은 먼저, 문제에 대해 바로 단순하게 생각해 낼 수 있는 해결책을 생각한 후에 패턴에서 제안하는 해결책과 비교하는 것이다.

현실적인 예시에 두 가지 해결책을 모두 적용해 보는 것도 이러한 개념을 습득하는 데에 많은 도움을 준다.

이러한 과정을 거친 후에야 특정한 패러다임의 관점에서 패턴에 대해 이야기할 수 있다.

예시를 위해 chain of responsibility 패턴을 살펴보자

What problem does it solve?

여러 개의 독립된 작업들은 하나의 액션에 대한 응답으로 실행되어야 한다.

각각의 작업들은 서로 다른 그룹, 다른 순서, 문맥에 따라서 실행되고, 하나의 작업에 대한 결과로 인해 전체 코드의 실행을 중지해야 할 수도 있다.

What is the naïve solution?

모든 대기열(큐)의 작업들을 하나의 개체(함수 혹은 클래스 메서드)로 정의하고 액션이 실행될 때마다 작업을 실행시킨다.

새로운 문맥(작업)은 동일한 타입의 추가 개체로 정의된다.

What is the solution proposed by the pattern?

각각의 응답을 각자의 개체로 이동시킨다. (즉 핸들러)

각 컨텍스트에 대한 핸들러를 서로 다른 대기열과 순서로 배치한다.

각 핸들러에게 작업을 처리하거나, 다음 핸들러로 넘기거나, 중지할 수 있는 기능을 부여한다.

현실적인 예

간단한 배틀 시스템을 가진 브라우저 기반 RPG 게임을 만들고 있다고 가정하자.

MVP(최소 기능 제품)의 일부로, 먼저 아이템을 이용해 공격 혹은 방어가 가능한 두 캐릭터를 생성할 수 있다.(Ninja , Monster)

직관적으로 생각했을 때의 공격 시스템은 이런식으로 구현될 수 있다.

출처: https://medium.com/arctouch/how-to-study-design-patterns-as-a-web-developer-e54284958e48

MVP승인 이후 프로덕트 팀은 공격을 수정하거나 무효화 할 수 있는 다른 아이템과 능력을 가진 Wizard와 Ghost, 2개의 새로운 캐릭터를 추가하기로 결정했다.

출처: https://medium.com/arctouch/how-to-study-design-patterns-as-a-web-developer-e54284958e48

아마 컨트롤 하기에는 너무 복잡해졌다고 느낄 것이다.

새로운 캐릭터마다 공격 기능에 대한 함수를 여러 번 작성해 줘야 할 뿐 아니라,

장착할 수 있는 아이템이 완전히 동일하지 않기 때문에

(예를 들어, wizard는 ninja처럼 sword를 사용할 수 있지만, ghost는 monster처럼 shield를 들 수 없다.)

아이템에 대한 코드를 각 캐릭터의 공격 기능 함수에 따로 반복해서 적어주어야 한다.

셀 수 없는 단위 테스트와 수동 테스트를 거쳐 이제 출시해도 되겠다고 느낄 만큼의 자신감이 생긴다.

몇 주 후에 당신의 최악의 악몽은 현실이 된다.

=> 당신의 MVP의 두 번째 사이클이 굉장히 성공적이어서 프로덕트 팀은 최소 10개의 새로운 캐릭터와 각 캐릭터마다 공격을 특정한 방법으로 수정할 수 있는 20개의 아이템을 추가하기로 결정했다.

naïve 한 해결책을 통한 유지보수와 확장은 불가능한 작업임이 증명되었다.

Applying the pattern

첫 번째로알 수 있는 점은, 공격은 액션이고 아이템은 액션에 대응하는 응답이라는 것이다. 따라서, 각 아이템을 액션 핸들러에 따라 쉽게 분류할 수 있고 게임 상태에 따라 대기열내에 모을 수 있다.

출처: https://medium.com/arctouch/how-to-study-design-patterns-as-a-web-developer-e54284958e48

Implementing a pattern

패턴을 추상적이고 패러다임 독립 개념의 관점에서 설명한 후에야 패러다임 종속 구조를 사용하여 실제로 구현해 볼 수 있다.

이러한 순서로 작업을 진행했을 때, 우리는 클래스 다이어그램을 이용했다면 찾지 못했을 여러 구현 방법을 알게 된다.

Chain of Responsibility(CoR)를 구현해 보기 위해 고전적인 oop방식으로 구현을 해보려고 한다.

하지만 여기서 구현하고 멈추면 안된다. 클래스와 객체가 사용되지 않는 함수의 합성과 함수의 배열만으로도 충분히 패턴을 구현할 수 있다.

OOP implementation

전통적인 CoR의 구현은 작업 큐에 모아놓기 위해 객체 구성을 사용한다. 각 작업은 클래스로 구현되며, 작업 큐의 다음 작업을 가리키는 next라는 레퍼런스를 포함하고 있다.

일반적으로, 레퍼런스는 모든 핸들러에 의해 확장될 수 있는 추상 클래스 내에서 캡슐화되어 있다.

타입 스크립트로구현한 간단한 예제

interface Item {
  new (next: Item): Item;
  next: Item;
  process: (attack: Attack) => Attack
};
abstract class BaseItem implements Item {
  constructor(public next: Item) {}
  abstract process(attack: Attack): Attack;
}
class Sword extends BaseItem {
  process(attack: Attack) {
    const copy = { ...attack, attack.strength *= 3 };
    return this.next ? this.next.process(copy) : copy;
  }
}
class GhostlyShape extends BaseItem {
  process(attack: Attack) {
    if (attack.isPhysical()) return null;
    else next(attack);
  }
}

이것은 GoF책에서도 볼 수 있고, 블로그 글에서 가장 많이 찾아볼 수 있는 구현 예시이다.

Refactorin Guru에서는 이것은 어떻데 프로젝트에서 활용해야 하는지에 대한 좋은 예시를 보여준다.

Closure-based implementation

CoR을 함수 구성으로 사용하기 위해서는 클로저의 개념을 이해해야 한다.

클로저는 함수 밖에서 함수 스코프를 가지는 변수에 접근할 수 없게 된 후에도, 생성 당시 스코프를 유지하고 있는 변수를 계속 참조하고 있는 (기술? 현상?)이다. (본문에서는 생성 당시 스코프를 유지하고 있는 변수를 계속 참조하고 있는 함수라고 설명)

클로저 기반의 CoR은 작업 큐 내 다음 핸들러를 가리키는 래퍼런스(next)를 유지하기 위해서 핸들러의 초기 스코프를 이용한다.

간단한 타입스크립트 구현 예시

type Modifier = (attack: Attack) => Attack;
type Item = (next?: Modifier) => Modifier;
const sword: Item = next => attack => {
  const copy = { ...attack, strength: attack.strength * 3 };
  return next ? next(copy) : copy;
}
const ghostlyShape: Item = next => attack => {
  if (isPhysical(attack) return null;
  else next(attack);
}

핸들러의 조합을 간단한 compose를 사용하여 처리할 수도 있다.

compose는 배열의 다음 항목으로 각 항목을 호출하며, 이는 다음 변수의 클로저에 의해 유지된다. 항목은 next를 호출하여 실행을 다음 핸들러로 전달하거나 중지할 수 있다.

CoR as an array of functions

이것은 CoR을 구현하는 가장 간단한 방법이다. 그래서 오히려 사람들이 패턴으로 생각하지 않는다.

작업 큐는 순서대로 호출되는 간단한 함수의 배열로 구현될 수 있다.

function sword (attack) {
  return { ...attack, strength: attack.strength * 3 };
};
function getAttack() {
  const { attacker, foe } = game.state;
  const modifiers = [
    ...attacker.attackItems,
    ...foe.defenseItems
  ];
  return modifiers.reduce((acc, currentItem) => {
    return currentItem(acc);
  }, attacker.getAttack());
}

위 접근방법의 장점은 간단하다는 것이다.

단점은 복잡하게 추가하지 않으면 실행을 중단하기 어렵다는 것이다.

Real-world applications

실제로 현업에서 일을 할 때, 혹은 프로젝트를 진행할 때의 예시를 포함하지 않는다면, 프런트엔드 개발자가 디자인 패턴을 공부해야 한다는 주장은 그저 moot point에 불과하게 된다.

moot point : 현재 상황과 관련이 없기 때문에 중요하지 않은 사실

CoR패턴은 프로젝트를 사용자의 의지에 따라 확장성 있게 만들어준다는 점에서 이미 강력한 도구임을 증명했으며, 몇몇의 성공적인 JS라이브러리들은 이러한 점을 위해 CoR패턴을 사용한다.

리덕스와 웹팩이 각각 CoR과 함수 composition, 함수배열을 사용하여 어떻게 개발자들이 기능을 확장하여 사용할 수 있도록 만들었는지 살펴보자

Redux Middleware

리덕스 문서는 dispatch 함수의 응답 내에서 실행되는, 개발자가 정의한 동작을 설치할 수 있도록 applyMiddleware API에 대해 설명되어 있다.

각 middleware는 리덕스 API에 접근 가능하고, 위에서 보았던 클로저 기반 CoR구현과 정확히 같은 방법을 사용하는 핸들러를 반환하는 factory function에 의해 생성된다.

function actionLogger({ getState }) {
  return next => action => {
    console.group(`Action of type ${action.type}`);
    console.log('action:', JSON.stringify(action, null, 1));
    console.log('prev state:', getState());
    console.groupEnd();
    return next(action);
  }
}

내부적으로 리덕스는 접근 가능한 API를 통해 factory function을 호출한 후에 compose를 사용하여 반환된 핸들러들을 모아놓는다. (source code here.)

이러한 접근은 action-based fetching solutions부터 function action types의 범위까지 리덕스가 무수히 많은 커스텀 된 동작들로 확장될 수 있도록 해주었다.

Redux Ecosystem page에서 리덕스에서 제공하는 CoR이 적용된 커스텀 기능들에 대한 리스트를 볼 수 있다.

Webpack loader

웹팩의 핵심기능은 규칙(test와 loader들을 사용하여 어떻게 소스파일을 다룰 것인지를 명시한 객체)으로 구현된다.

매번 파일은 의존성 그래프에 추가되고 런타임은 정의된 테스트를 사용하여 하나의 규칙과 일치시킨다.

그 후, 일치 규칙에 의해 명시된 loader chain이 해당 소스에 적용되어 webpack이 임의의 언어를 변환하여 JS로 출력할 수 있게 된다.

웹팩 설정 예시

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          { loader: 'style-loader' },
          {
            loader: 'css-loader',
            options: { modules: true }
          },
          { loader: 'sass-loader' }
        ]
      }
    ]
  }
};

loader chain들은 reverse order of declaration이라고 하는 CoR의 함수의 배열을 사용하여 구현되었다.

각 loader는 체인에 존재하는 다음 로더의 출력으로 인해 실행되고 마지막 순서의 로더는 유효한 자바스크립트 코드를 제공할 것으로 예상한다.

체인 내에서 실행을 중지하거나 다음 노드로 넘어가기 위해 각 로더들은 this.emitError, this.callback과 같이 this객체에 바인딩되어있는 함수를 사용할 수 있다.

값을 반환하는 방식으로도 동일한 작업을 실행할 수 있다.

Other patterns

다른 많은 라이브러리들은 디자인의 단순성을 유지하며 확장성을 최대로 가져가기 위해 패턴들을 광범위하게 사용한다.

예시:

React는 Composite(합성) 패턴을 활용하여 렌더링 할 수 있는 작은 ui 단위들을 이용해, 복잡한 ui를 구현한다.
React-Redux는 React의 컴포넌트들을 Redux store의 데이터와 연결하기 위해 dercorator패턴을 사용한다.
Vue는 상태 관리에 따른 ui의 rerender를 위해 Observer패턴을 광범위하게 사용한다.
Babel은 plugin들이 소스코드를 검사하고 수정할 수 있도록 Visitor패턴을 사용한다.

디자인 패턴의 사용 예는 비단, 라이브러리에만 국한되지 않으며 당신의 애플리케이션에서도 이 글에서 논의된 디자인 패턴들의 개념을 사용하여 동일한 결과를 얻을 수 있다.

결론

디자인 패턴에 대한 깊은 이해는 소프트웨어 개발자가 가질 수 있는 가장 강력한 도구 중 하나이다.

이 귀중한 개념들이 오랫동안 객체지향적 설계를 설명하는 관점에서만 사용되었기 때문에

충분히 자신의 코드와 프로젝트의 질을 높일 수 있는 프론트엔드 개발자들에게서 이러한 개념들을 멀어지게 만들었다.

다행히, 패턴들은 일반적인 상황에서 마주치는 문제의 해결책에 대해 설명해주기 때문에

틀림없이 프론트엔드 개발자들은 그들의 커리어 중에 몇몇 패턴들을 자연스럽게 다시 찾아보게 될 것이다.

해결책을 모두가 아는 명칭을 사용한다면 팀과 소통하기 훨씬 수월해질 것이다.

그러니 클래스 다이어그램을 통해 가르치는 패턴을 발견한다면 포기하지 말자.

이 글에서 설명된 과정을 적용한다면 당신은 어떤 패턴이라도 마스터 하고 당신의 무기고에서 강력한 무기를 만들 수 있다.

원문

https://medium.com/arctouch/how-to-study-design-patterns-as-a-web-developer-e54284958e48

How To Study Design Patterns as a Web Developer

A framework for describing Design Patterns in a paradigm-independent fashion

medium.com

타입스크립트 프로그래밍 2주차

JWOOKJ — Fri, 25 Feb 2022 21:37:12 +0900

타입스크립트 프로그래밍 2주차

함수

함수의 선언과 실행

타입스크립트에서 함수를 실행할 경우 반환값은 타입추론이 가능하지만 특별한 상황이 아닌 이상 매개변수의 타입은 추론하지 않는다.

매개변수의 타입은 개발자가 직접 명시해 주어야 한다.

//매개변수 타입 지정
const human = (name: string, age: number) => {
	return `name is ${name}, age is ${age}`
}

console.log(human("Jay", 12))
//name is Jay, age is 12

//매개변수 타입 미지정
const human = (name, age) => {
	return `name is ${name}, age is ${age}`
}

console.log(human("Jay", 12))
//Parameter 'name' implicitly has an 'any' type.
//Parameter 'age' implicitly has an 'any' type.

//매개변수와 반환 타입 지정
const human = (name: string, age: number): string => {
	return `name is ${name}, age is ${age}`
}

console.log(human("Jay", 12))
//name is Jay, age is 12

* 본 책에서는 반환 타입을 명시할 수 있으나 타입스크립트의 타입추론은 강력한 기능이기 때문에 특별한 경우가 아닌 이상 개발자가 굳이 명시할 필요는 없다고 설명하고 있다.

* 타입스크립트에서 함수를 함수 생성자 (new Function()) 통해 함수를 선언하는 것은 매개변수 타입과 반환 타입을 지정해 줄 수 없기 때문에 안전하지 않다.

선택적 매개변수, 기본 매개변수, 나머지 매개변수

함수에서 사용할 수도, 사용하지 않을 수도 있는 매개변수는 ?를 사용해 선택적 매개변수로 명시하여 준다.

기본값을 가지게 되는 매개변수는 = 연산자를 통해 기본 매개변수로 명시하여 준다.

타입스크립트에서의 arguments 객체는 인수들의 타입을 모두 any로 취급하기 때문에 안전하지 않다. arguments객체 대신 전개구문(Spread Syntax)을 사용하여 명시해 준다.

//선택적 매개변수
let sum = (a:number, b:number, c?:number) => {
 return c ?  a + b + c : a + b
}
console.log(sum(1, 2, 3))
//6
console.log(sum(1, 2))
//3

//선택적 매개변수를 명시하지 않고 함수의 인수를 모자르게 입력했을 경우
let sum = (a:number, b:number, c:number) => {
 return c ?  a + b + c : a + b
}
console.log(sum(1, 2))
//Expected 3 arguments, but got 2.

//기본 매개변수
let sum = (a:number, b:number, c = 5) => {
 return c ?  a + b + c : a + b
}
console.log(sum(1, 2))
//8
console.log(sum(1, 2, 3))
//6

//나머지 매개변수
let sum = (...array : number[]) => {
 return array.reduce((total, n) => total + n, 0) 
}

console.log(sum(1, 2, 3))
//6

* 기본 매개변수 사용시에도 타입을 명시해 줄 수 있지만 (c:number = 3)타입스크립트의 타입추론을 통해 기본값의 타입으로 매개변수의 타입을 지정해 주기 때문에 특별한 경우가 아닌 이상 따로 타입을 명시해 줄 필요가 없다.

호출 시그니처(타입 시그니처)

타입 수준 코드로 함수의 전체 타입을 지정할 때 사용한다.

//단축 시그니처
type Greet = (name: string) => string

//전체 시그니처
type Greet = {
 (name: string): string
}

const greet: Greet = (name) => `Hi ${name}!`
console.log(greet("Jay"))
//Hi Jay!

* 함수의 타입(Greet)에 이미 매개변수의 타입과 반환 타입을 지정해 주었으므로 함수를 선언할 때 다시 타입을 지정할 필요가 없다.

오버로드 시그니처

호출 시그니처가 여러 개인 함수

//Reservation이라는 타입을 선언했다는 가정하에 Reserve 타입 선언
//타입 시그니처
type Reserve = {
    //왕복 예약
    (from: Date, to: Date, destination: string): Reservation
    //편도 예약
    (from: Date, destination: string): Reservation
}

//구현 시그니처
let reserve: Reserve = (
    from: Date,
    toOrDestination: Date | string,
    destination?: string
) => {...}

* 오버로드 시그니처를 구현할 경우에는 오버로드 시그니처를 직접 결합하여 선언해 주어야 한다.

* 오버로드 시그니처를 구현할 경우에는 가능한한 타입을 특정하는 것이 좋다. (any 대신 stirng | Date등)

다형성(generic)

함수의 매개변수 혹은 반환값의 타입을 지정할 수 없는 상황에는 제네릭 타입을 사용하여 해결할 수 있다.

제네릭 타입은 꺽쇠를 사용하여 표현해 준다. <T>

type Filter = {
    <T>(array: T[], f: (item: T) => boolean): T[]
}

* 위의 예에서 Filter라는 타입으로 구현한 함수를 호출할 때 타입스크립트는 인수로 받은 배열의 요소들의 타입을 추론하여 해당 타입을 제네릭 타입 <T>에 할당한다.

* 제네릭 타입의 변수는 꼭 T로 하지 않아도 상관없다.

프린터

JWOOKJ — Mon, 7 Feb 2022 21:30:26 +0900

#문제

일반적인 프린터는 인쇄 요청이 들어온 순서대로 인쇄합니다. 그렇기 때문에 중요한 문서가 나중에 인쇄될 수 있습니다. 이런 문제를 보완하기 위해 중요도가 높은 문서를 먼저 인쇄하는 프린터를 개발했습니다. 이 새롭게 개발한 프린터는 아래와 같은 방식으로 인쇄 작업을 수행합니다.

1. 인쇄 대기목록의 가장 앞에 있는 문서(J)를 대기목록에서 꺼냅니다.
2. 나머지 인쇄 대기목록에서 J보다 중요도가 높은 문서가 한 개라도 존재하면 J를 대기목록의 가장 마지막에 넣습니다.
3. 그렇지 않으면 J를 인쇄합니다.

예를 들어, 4개의 문서(A, B, C, D)가 순서대로 인쇄 대기목록에 있고 중요도가 2 1 3 2 라면 C D A B 순으로 인쇄하게 됩니다.

내가 인쇄를 요청한 문서가 몇 번째로 인쇄되는지 알고 싶습니다. 위의 예에서 C는 1번째로, A는 3번째로 인쇄됩니다.

현재 대기목록에 있는 문서의 중요도가 순서대로 담긴 배열 priorities와 내가 인쇄를 요청한 문서가 현재 대기목록의 어떤 위치에 있는지를 알려주는 location이 매개변수로 주어질 때, 내가 인쇄를 요청한 문서가 몇 번째로 인쇄되는지 return 하도록 solution 함수를 작성해주세요.

제한사항

현재 대기목록에는 1개 이상 100개 이하의 문서가 있습니다.
인쇄 작업의 중요도는 1~9로 표현하며 숫자가 클수록 중요하다는 뜻입니다.
location은 0 이상 (현재 대기목록에 있는 작업 수 - 1) 이하의 값을 가지며 대기목록의 가장 앞에 있으면 0, 두 번째에 있으면 1로 표현합니다.

입출력 예

prioritieslocationreturn

[2, 1, 3, 2]	2	1
[1, 1, 9, 1, 1, 1]	0	5

입출력 예 설명

예제 #1

문제에 나온 예와 같습니다.

예제 #2

6개의 문서(A, B, C, D, E, F)가 인쇄 대기목록에 있고 중요도가 1 1 9 1 1 1 이므로 C D E F A B 순으로 인쇄합니다.

#나의 풀이

const solution = (priorities, location) => {
  //출력 횟수
  let count = 1;
  while (priorities.length !== 0) {
    //리스트내 가장 큰 숫자의 인덱스
    let bigIndex = priorities.indexOf(Math.max(...priorities));
    //location과 bigIndex가 같을 경우 바로 count값 return
    if (location === bigIndex) {
      return count;
    }
    let length = priorities.length;
    //배열의 첫 인자부터 bigIndex앞의 인자까지 배열을 자른다
    let moveBackArray = priorities.splice(
      0,
      priorities.indexOf(Math.max(...priorities))
    );
    //자른 배열을 뒤로 붙임
    priorities = [...priorities, ...moveBackArray];
    //배열의 변경에 따른 location 변수의 변경
    location < bigIndex
      ? (location += length - bigIndex)
      : (location -= bigIndex);
    //변경된 배열에서 가장 앞의 인자(가장 큰 값을 가진 인자)제거
    priorities.shift();
    //배열의 길이가 줄었으므로 location도 1 줄어듬
    location -= 1;
    //가장 큰 수가 하나 출력됬으므로 count 증가
    count++;
  }
};

기능개발

JWOOKJ — Mon, 7 Feb 2022 21:24:37 +0900

#문제

프로그래머스 팀에서는 기능 개선 작업을 수행 중입니다. 각 기능은 진도가 100%일 때 서비스에 반영할 수 있습니다.

또, 각 기능의 개발속도는 모두 다르기 때문에 뒤에 있는 기능이 앞에 있는 기능보다 먼저 개발될 수 있고, 이때 뒤에 있는 기능은 앞에 있는 기능이 배포될 때 함께 배포됩니다.

먼저 배포되어야 하는 순서대로 작업의 진도가 적힌 정수 배열 progresses와 각 작업의 개발 속도가 적힌 정수 배열 speeds가 주어질 때 각 배포마다 몇 개의 기능이 배포되는지를 return 하도록 solution 함수를 완성하세요.

제한 사항

작업의 개수(progresses, speeds배열의 길이)는 100개 이하입니다.
작업 진도는 100 미만의 자연수입니다.
작업 속도는 100 이하의 자연수입니다.
배포는 하루에 한 번만 할 수 있으며, 하루의 끝에 이루어진다고 가정합니다. 예를 들어 진도율이 95%인 작업의 개발 속도가 하루에 4%라면 배포는 2일 뒤에 이루어집니다.

입출력 예

progressesspeedsreturn

[93, 30, 55]	[1, 30, 5]	[2, 1]
[95, 90, 99, 99, 80, 99]	[1, 1, 1, 1, 1, 1]	[1, 3, 2]

입출력 예 설명

입출력 예 #1
첫 번째 기능은 93% 완료되어 있고 하루에 1%씩 작업이 가능하므로 7일간 작업 후 배포가 가능합니다.
두 번째 기능은 30%가 완료되어 있고 하루에 30%씩 작업이 가능하므로 3일간 작업 후 배포가 가능합니다. 하지만 이전 첫 번째 기능이 아직 완성된 상태가 아니기 때문에 첫 번째 기능이 배포되는 7일째 배포됩니다.
세 번째 기능은 55%가 완료되어 있고 하루에 5%씩 작업이 가능하므로 9일간 작업 후 배포가 가능합니다.

따라서 7일째에 2개의 기능, 9일째에 1개의 기능이 배포됩니다.

입출력 예 #2
모든 기능이 하루에 1%씩 작업이 가능하므로, 작업이 끝나기까지 남은 일수는 각각 5일, 10일, 1일, 1일, 20일, 1일입니다. 어떤 기능이 먼저 완성되었더라도 앞에 있는 모든 기능이 완성되지 않으면 배포가 불가능합니다.

따라서 5일째에 1개의 기능, 10일째에 3개의 기능, 20일째에 2개의 기능이 배포됩니다.

#나의 풀이

//maxDays의 값을 반환하는 함수
const setMaxDays = (index, progressArray, speedArray) => {
  return Math.ceil((100 - progressArray[index]) / speedArray[index]);
};

const solution = (progresses, speeds) => {
  //전역 변수 초기화
  let answer = [];
  let funcCount = 1;
  let maxDays = setMaxDays(0, progresses, speeds);
  for (let i = 1; i < progresses.length; i++) {
    const currentDays = setMaxDays(i, progresses, speeds);
    //maxDays보다 걸리는 기간이 적을 경우
    if (maxDays >= currentDays) {
      funcCount++;
      //maxDays보다 걸리는 기간이 클 경우
    } else {
      answer.push(funcCount);
      funcCount = 1;
      maxDays = currentDays;
    }
    //작업목록의 마지막 인자일 경우
    if (i === progresses.length - 1) {
      answer.push(funcCount);
    }
  }
  return answer;
};

베스트 앨범

JWOOKJ — Mon, 7 Feb 2022 21:04:54 +0900

#문제

스트리밍 사이트에서 장르 별로 가장 많이 재생된 노래를 두 개씩 모아 베스트 앨범을 출시하려 합니다. 노래는 고유 번호로 구분하며, 노래를 수록하는 기준은 다음과 같습니다.

속한 노래가 많이 재생된 장르를 먼저 수록합니다.
장르 내에서 많이 재생된 노래를 먼저 수록합니다.
장르 내에서 재생 횟수가 같은 노래 중에서는 고유 번호가 낮은 노래를 먼저 수록합니다.

노래의 장르를 나타내는 문자열 배열 genres와 노래별 재생 횟수를 나타내는 정수 배열 plays가 주어질 때, 베스트 앨범에 들어갈 노래의 고유 번호를 순서대로 return 하도록 solution 함수를 완성하세요.

제한사항

genres[i]는 고유번호가 i인 노래의 장르입니다.
plays[i]는 고유번호가 i인 노래가 재생된 횟수입니다.
genres와 plays의 길이는 같으며, 이는 1 이상 10,000 이하입니다.
장르 종류는 100개 미만입니다.
장르에 속한 곡이 하나라면, 하나의 곡만 선택합니다.
모든 장르는 재생된 횟수가 다릅니다.

입출력 예

genresplaysreturn

["classic", "pop", "classic", "classic", "pop"]

[500, 600, 150, 800, 2500]

[4, 1, 3, 0]

입출력 예 설명

classic 장르는 1,450회 재생되었으며, classic 노래는 다음과 같습니다.

고유 번호 3: 800회 재생
고유 번호 0: 500회 재생
고유 번호 2: 150회 재생

pop 장르는 3,100회 재생되었으며, pop 노래는 다음과 같습니다.

고유 번호 4: 2,500회 재생
고유 번호 1: 600회 재생

따라서 pop 장르의 [4, 1]번 노래를 먼저, classic 장르의 [3, 0]번 노래를 그다음에 수록합니다.

#나의 풀이

const solution = (genres, plays) => {
  let answer = [];
  //주어진 배열들을 map구조로 정리할 변수 선언
  const genreMap = new Map();
  //내림차순 정렬에 사용될 callback함수 선언
  const sortByDescending = (a, b) => {
    return b - a;
  };

  //선언한 genreMap에 key(genre) value(total, lists)값으로 할당
  genres.map((_genre, _idx) => {
    //각 음악의 고유번호, 재생횟수 배열형태로 선언
    const eachSongInfo = [_idx, plays[_idx]];
    //genreMap내 해당 genre가 key값으로 존재할 경우 total과 lists값 수정 존재하지 않을 경우 새로 생성
    if (!genreMap.has(_genre)) {
      genreMap.set(_genre, { total: plays[_idx], lists: [eachSongInfo] });
    } else {
      //genreMap내 존재하는 genre의 값을 eachGenre 변수에 할당
      const eachGenre = genreMap.get(_genre);
      genreMap.set(_genre, {
        total: eachGenre.total + plays[_idx],
        lists: [...eachGenre.lists, eachSongInfo],
      });
    }
  });

  //정리된 genreMap을 배열형태로 변환
  const genreArray = Array.from(genreMap);

  //total값 내림차순 정렬
  genreArray.sort((a, b) => sortByDescending(a[1].total, b[1].total));

  //각 장르별 lists의 plays값들을 내림차순으로 정렬
  for (let i = 0; i < genreArray.length; i++) {
    genreArray[i][1].lists.sort((a, b) => sortByDescending(a[1], b[1]));
    //lists의 plays값이 높은 최대 2개의 고유번호값을 answer배열에 추가
    if (genreArray[i][1].lists.length < 2) {
      answer.push(genreArray[i][1].lists[0][0]);
    } else {
      for (let j = 0; j < 2; j++) {
        answer.push(genreArray[i][1].lists[j][0]);
      }
    }
  }
  return answer;
};

#다른 풀이

function solution(genres, plays) {
    var dic = {};
    genres.forEach((t,i)=> {
        dic[t] = dic[t] ?  dic[t] + plays[i] :plays[i];        
    });

    var dupDic = {};
    return genres          
          .map((t,i)=> ({genre : t, count:plays[i] , index:i}))
          .sort((a,b)=>{               
               if(a.genre !== b.genre) return dic[b.genre] - dic[a.genre];
               if(a.count !== b.count) return b.count - a.count;
               return a.index - b.index;
           })
           .filter(t=>  {
               if(dupDic[t.genre] >= 2) return false;
               dupDic[t.genre] = dupDic[t.genre] ? dupDic[t.genre]+ 1 : 1;
               return true;
            })
           .map(t=> t.index);    
}

* 굳이 자바스크립트의 Map객체를 사용하지 않아도 되지만 Map객체에 대해 좀 더 알기 위해 사용해 보았다.