bae-sh.log

DebounceClick 컴포넌트를 알아보자 (feat. toss/slash)

Sun, 26 May 2024 10:10:46 GMT

Toss의 오픈소스 라이브러리인 slash에 DebounceClick 이라는 유틸 컴포넌트가 있습니다. 어떤 방식으로 Slash에서는 구현을 했을까 궁금하여 코드를 분석해보며 로직이나 타입에 대해 배울것이 많아 정리해보려고 합니다.

Debounce 란?

분석에 앞서 Debounce에 대해서 간단하게 알아 봅시다.

Debounce는 자바스크립트에서 특정 이벤트가 일정 시간 동안 반복해서 발생하는 것을 제어하는 기법입니다. 주로 사용자가 입력 필드에 타이핑을 할 때마다 발생하는 이벤트나 스크롤 이벤트와 같이 자주 발생하는 이벤트를 처리할 때 유용합니다. debounce를 사용하면 특정 시간 동안 이벤트가 발생하지 않을 때까지 이벤트 핸들러가 호출되지 않도록 할 수 있습니다.

대표적인 예시로 velog의 검색 필터링이 있습니다.

velog에서는 검색어를 기반으로 포스트를 graphql로 요청하는데요. 검색어를 치고 몇초뒤에 api가 호출되는것을 확인할 수 있습니다. 또한 검색어를 계속 치고있을경우 api 호출이 발생하지 않는것 또한 볼 수 있습니다.

이렇게 Debounce를 사용하여 리소스를 서버에 무리하게 요청하는 문제를 막을 수 있습니다.

DebounceClick Component

그럼 본격적으로 slash에서는 어떤식으로 DebounceClick 컴포넌트를 구현하였는지 알아봅시다.

DebounceClick 컴포넌트는

click event에 debounce를 적용할 수 있는 유틸 컴포넌트입니다.

라고 설명을 하고 있습니다.

내부 코드는 다음과 같습니다.

import { Children, cloneElement, ReactElement } from 'react';
import { useDebounce } from '../../hooks/useDebounce';

/** @tossdocs-ignore */
interface Props {
  /**
   * @description 이벤트를 묶어서 한번에 보낼 시간으로 ms 단위
   * e.g.) 200ms 일 때, 200ms 안에 발생한 이벤트를 무시하고 마지막에 한번만 방출합니다.
   */
  wait: Parameters[1];
  options?: Parameters[2];
  children: ReactElement;
  /**
   * @default 'onClick'
   * @description 이벤트 Prop 이름으로 'onClick' 이름 외로 받을 때 사용합니다.
   * e.g. "onCTAClick", "onItemClick" ...
   */
  capture?: string;
}

export function DebounceClick({ capture = 'onClick', options, children, wait }: Props) {
  const child = Children.only(children);
  const debouncedCallback = useDebounce(
    (...args: any[]) => {
      if (child.props && typeof child.props[capture] === 'function') {
        return child.props[capture](...args);
      }
    },
    wait,
    options
  );

  return cloneElement(child, {
    [capture]: debouncedCallback,
  });
}

코드는 많이 복잡하지는 않네요. DebounceClick 컴포넌트에 delay시간, 옵션 등을 props로 받고 child의 capture(onClick)에 해당하는 함수를 useDebounce에 할당하는 모습입니다. 그 뒤 child의 컴포넌트를 cloneElement 함수를 통해서 return 해주고 있네요. 여기서 React의 몇몇 함수와 타입이 낯선것들이 있었는데요. 하나하나 분석해 봅시다.

Type

Parameters

함수 타입의 매개변수 타입을 추출하는 TS 내장 유틸리티 타입

개발을 진행하며 특정 함수의 매개변수와 동일한 타입을 가져오고 싶을 경우가 있잖아요? 이럴때 사용하면 유용할 것 같습니다. 여기서는 wait과 options 에서 사용되었는데요. useDebounce 함수의 파라미터의 1번째 인자와 2번째 인자의 타입을 받아옴을 알 수 있습니다.

ReactElement

React 라이브러리에서 사용되는 기본적인 타입 중 하나로, React 컴포넌트가 반환하는 요소를 표현하는 타입

Ts에서 정의하는 ReactElement

interface ReactElement = string | JSXElementConstructor> {
  type: T;
  props: P;
  key: Key | null;
}

React에서 렌더링 하기위해서 사용되는 element를 표현하는 타입입니다. 위 예시에서는 children을 필수적으로 받으며 ReactElement 하나만 받도록 되어있네요.

유사하게 ReactNode 라는 타입도 존재하는데요. ReactNode는 React가 렌더링할 수 있는 모든 종류의 값을 나타내며 좀 더 포괄적인 타입입니다.

ReactNode에는 다음과 같은 타입을 허용합니다

문자열, 숫자, boolean (true/false는 렌더링되지 않지만 타입으로 허용됨)
ReactElement
ReactFragment
배열 (중첩된 ReactNode 포함)
null 또는 undefined

여기까지 DebounceClick 의 Props 타입에 대해서 정리해 보았습니다. 다음으로는 사용한 React 유틸리티를 알아봅시다.

React Utility

export function DebounceClick({ capture = 'onClick', options, children, wait }: Props) {
  const child = Children.only(children);
  const debouncedCallback = useDebounce(
    (...args: any[]) => {
      if (child.props && typeof child.props[capture] === 'function') {
        return child.props[capture](...args);
      }
    },
    wait,
    options
  );

  return cloneElement(child, {
    [capture]: debouncedCallback,
  });
}

Children

React의 Children는 React 컴포넌트의 자식 요소를 다루기 위한 유틸리티입니다.이를 통해 부모 컴포넌트에서 자식 컴포넌트를 효율적으로 다루고 관리할 수 있습니다. Children이 사용할 수 있는 메서드는 여러가지 존재하지만 이곳에서 사용된 only에 대해서만 알아봅시다.

only

자식 요소가 정확히 하나인지 확인하고, 그렇지 않으면 오류를 발생시킵니다. DebounceClick 에서는 Children.only(children) 를 통해 children이 항상 1개임을 명시하기 위해 사용한 것 같습니다. Props에서 children: ReactElement; 를 통해 2개 이상의 child가 있을 경우 타입에러가 발생하지만 js를 위해서 한번 더 사용한 것으로 보입니다.

cloneElement

cloneElement는 React에서 기존의 React 요소를 복제하고, 추가적으로 props를 변경하거나 덮어쓰는 기능을 제공하는 유틸리티 함수입니다. 이를 사용하면 기존 요소의 구조를 유지하면서 새로운 속성을 추가하거나 기존 속성을 수정할 수 있습니다.

기본적인 문법은 다음과 같습니다.

cloneElement(
  element,   // 복제할 요소
  [props],   // 새로 추가하거나 덮어쓸 props
  [...children] // element의 새로운 자식 요소 (선택 사항)
)

DebounceClick 에서는 기존의 child를 복사하되, capture(onClick)에 debounce 함수만 변경하는 방식으로 구현을 하였습니다. 결국 DebounceClick 컴포넌트는 Wrapper의 껍대기 역할만 하고 실제 child인 button에 debounce된 함수를 넣어주는 역할이 되겠네요.

정리

이렇게 Debounce에 대해서 간단하게 알아보며 toss/slash에서 사용하고 있는 DebounceClick가 어떤식으로 구현되어 있는지 보았습니다. 다양한 타입과 React 유틸리티 함수를 보며 적용해보고 싶은 생각이 드는데요. 읽어주셔서 감사합니다! 🙇🏻‍♂️

터미널에 npm start 를 치면 무슨일이 발생할까?

Sun, 28 Apr 2024 06:37:18 GMT

매번 리액트를 실행시키기 위해 npm start 혹은 npm run dev와 같은 명령어를 작성하면 리액트 서버가 켜지면서 우리가 작성한 웹페이지를 브라우저에서 확인할 수 있습니다. 수도없이 이 명령어를 실행했지만 막상 어떠한 과정을 통해서 이 웹서버가 켜지는지에 대해 생각해본적이 없어서 NPM 내부 코드를 학습해보며 정리하려 합니다.

NPM(Node Packaged Manager) 이란?

들어가기에 앞서 NPM에 대해서 간단하게 알아봅시다. 위키백과에서는 NPM을 다음과 같이 정의합니다

npm은 자바스크립트 프로그래밍 언어를 위한 패키지 관리자이다. 자바스크립트 런타임 환경 Node.js의 기본 패키지 관리자이다. 명령 줄 클라이언트, 그리고 공개 패키지와 지불 방식의 개인 패키지의 온라인 데이터베이스로 이루어져 있다. 위키백과

즉, Node.js로 만들어진 패키지들을 설치하고 관리해주는 프로그램입니다. 리액트 또한 하나의 패키지로 구성되어 있으며 NPM 사이트에서 확인할 수 있습니다.

패키지 내부에는 package.json 이라는 파일을 볼 수 있습니다. 이 파일은 패키지에 대한 명세서가 들어있다고 생각하시면 됩니다. 예를들면, 패키지 이름, 버전, 의존성, 스크립트 등등 말이죠... 여기서 스크립트는 해당 패키지의 명령어 들이 적혀있는데요. start,build,test 등등 다양한 명령어를 통해서 스크립트를 실행시킬 수 있습니다.

NPM Start

리액트 환경은 CRA로 설치하여 진행하였습니다. CRA를 설치하고 npm start를 입력하면 첫 CRA 페이지를 확인할 수 있습니다. 그전에 Package.json 파일을 봅시다.

CRA에서 기본적으로 제공하는 스크립트는 start, build, test, eject 정도가 있네요. 사실 우리가 위에서 실행한 start의 경우 npm이 pakage.json의 start에 해당하는 react-scripts의 start 명령어를 실행했다고 추측할 수 있습니다.

실행 코드

//lib/cli/entry.js
 try {
    const { exec, command, args } = await npm.load()

    ...
    const execPromise = npm.exec(command, args)

       ...
    updateNotifier(npm).then((msg) => (npm.updateNotification = msg))

    await execPromise
    return exitHandler()
  } catch (err) {
    ...
}

해당 코드는 npm 실행 시 진입점인 entry 파일의 일부 입니다. npm 을 실행하면 load 함수를 통해 command를 받아올 수 있고 해당 command를 기반으로 npm을 exec(실행) 한다고 추측할 수 있습니다.

그럼 npm의 load 함수를 확인해 봅시다.

//lib/npm.js

async load () {
  return time.start('npm:load', () => this.#load())
}

async #load () {

    ...

    // Remove first argv since that is our command as typed
    // Note that this might not be the actual name of the command
    // due to aliases, etc. But we use the raw form of it later
    // in user output so it must be preserved as is.
    const commandArg = this.argv.shift()

    // This is the actual name of the command that will be run or
    // undefined if deref could not find a match
    const command = deref(commandArg)

    ...

    return { exec: true, command: commandArg, args: this.argv }
}

이 코드는 npm.js 의 일부입니다. load 함수는 npm 객체의 #load를 호출하고 #load 함수는 npm start 명령어 중 npm을 제외한 start값이 commandArg에 들어갑니다. 이후 별칭임을 deref로 확인하고 반환합니다.

그럼 어떻게 start 커맨드가 exec함수에서 실행되는 지 따라가 봅시다.


 static cmd (c) {
    const command = deref(c)
    if (!command) {
      throw Object.assign(new Error(`Unknown command ${c}`), {
        code: 'EUNKNOWNCOMMAND',
        command: c,
      })
    }
    return require(`./commands/${command}.js`)
  }


 // Call an npm command
  async exec (cmd, args = this.argv) {
    const Command = Npm.cmd(cmd)
    const command = new Command(this)

    // since 'test', 'start', 'stop', etc. commands re-enter this function
    // to call the run-script command, we need to only set it one time.
    if (!this.#command) {
      this.#command = command
      process.env.npm_command = this.command
    }

    return time.start(`command:${cmd}`, () => command.cmdExec(args))
  }

이 함수에서는 cmd으로 'start' 값을 받을것이고 cmd를 통해 start.js의 객체를 받아옵니다. 그 객체 cmdExec 함수를 실행하는 군요.

class Start extends LifecycleCmd {
  static description = 'Start a package'
  static name = 'start'
  static params = [
    'ignore-scripts',
    'script-shell',
  ]
}

class LifecycleCmd extends BaseCommand {
  static usage = ['[-- ]']
  static isShellout = true
  static workspaces = true
  static ignoreImplicitWorkspace = false

  async exec (args) {
    return this.npm.exec('run-script', [this.constructor.name, ...args])
  }

  async execWorkspaces (args) {
    return this.npm.exec('run-script', [this.constructor.name, ...args])
  }
}

class BaseCommand {
    ...
  async cmdExec (args) {
    return this.exec(args)
  }
}

해당 부분이 조금 특이합니다. 집중해서 보셔야 하는데요. Start클래스는 LifecycleCmd를 상속받고 있고 LifecycleCmd는 BaseCommand를 상속 받고 있습니다. 이 cmdExec 함수는 BaseCommand의 cmdExec를 실행하고 있습니다. 또한 이 cmdExec 함수는 LifecycleCmd의 exec 함수를 실행하고 있고요.

이 LifecycleCmd의 exec 함수는 다시 NPM 객체의 run-script 커맨드를 실행합니다.

class RunScript extends BaseCommand {


  async exec (args) {
    if (args.length) {
      return this.run(args)
    } else {
      return this.list(args)
    }
  }


  async run ([event, ...args], { path = this.npm.localPrefix, pkg } = {}) {
    const runScript = require('@npmcli/run-script')

    const { scripts = {} } = pkg

    pkg.scripts = scripts

    // positional args only added to the main event, not pre/post
    const events = [[event, args]]

    for (const [ev, evArgs] of events) {
      await runScript({
        path,
        // this || undefined is because runScript will be unhappy with the
        // default null value
        scriptShell: this.npm.config.get('script-shell') || undefined,
        stdio: 'inherit',
        pkg,
        event: ev,
        args: evArgs,
      })
    }
  }
}

실행하면 아까와 같은 과정으로 run-script.js 파일의 Runscript 객체의 exec 이 실행됩니다. 이 exec은 run을 실행하고 pkg(package.json 객체)의 sciprt(react-scripts start)를 실행함을 할 수 있습니다.

react-scripts start

react-scrips start는 무슨의미 일까요? 이는 react-scripts 모듈을 start 하겠다는 의미로 해석 할 수 있습니다. node_modules에 있는 react-scripts는 다음과 같습니다.

여기서 bin 파일의 react-scripts.js가 실행이 되는데요. 왜 bin폴더의 파일이 실행되는지 코드로는 찾지 못하여서 관련 게시글을 통해 알 수 있었습니다. 참고

그럼 bin 폴더가 무엇일까요??

bin

Binary File 바이너리 파일이라고 부르며, 컴퓨터가 사용하는 이진 텍스트 파일입니다. 참고

npm에서는 package.json파일의 bin 프로퍼티에 bash script를 설정하여 권한 부여 없이 자동으로 실행할 수 있도록 도와줍니다.참고 또한, npm에서는 이부분부터 시작이 되어 스크립트의 엔트리 포인트로 추측이 되긴합니다.

react-scripts 내부

다시 돌아와서 이 스크립트 내부를 살펴보면 이전에 존재했던 4가지의 커맨드가 존재합니다.

const args = process.argv.slice(2);

const scriptIndex = args.findIndex(
  x => x === 'build' || x === 'eject' || x === 'start' || x === 'test'
);
const script = scriptIndex === -1 ? args[0] : args[scriptIndex];
const nodeArgs = scriptIndex > 0 ? args.slice(0, scriptIndex) : [];

if (['build', 'eject', 'start', 'test'].includes(script)) {
  const result = spawn.sync(
    process.execPath,
    nodeArgs
      .concat(require.resolve('../scripts/' + script))
      .concat(args.slice(scriptIndex + 1)),
    { stdio: 'inherit' }
  );
}

커맨드에 따라 스크립트 폴더 내부에 있는 커맨드 파일에 접근합니다. 저희 같은 경우에는 start.js 파일이 실행되겠죠?? 최종적으로 start.js 파일이 실행되고 내부에는 프로젝트를 번들링후 웹서버를 키는 동작과정으로 React 파일이 실행되게 됩니다.

결론

이렇게 npm start를 react 프로젝트에서 입력했을 경우에 어떤과정으로 통해 react 서버가 켜지는지 알아보았습니다. 마지막으로 전체적인 과정을 요약하며 마무리 하겠습니다. 읽어주셔서 감사합니다!

과정

CRA 프로젝트 환경에서 npm start 입력

npm은 package.json script의 start 값을 확인

scirpt에 적혀있는 react-scripts start를 확인

node_modules에 react-scripts를 확인하고, package.json의 bin에 명시되어있는 react-scripts.js 파일 접근

여러 커맨드 중 입력 받은 start.js의 파일에 접근

프로젝트 번들링과 웹서버 실행

Tailwindcss 오픈소스 기여 과정기

Tue, 16 Apr 2024 10:54:16 GMT

계기

tailwindcss는 현재 프론트엔드 분야에서 스타일링을 위해 많이 쓰이는 라이브러리 중 하나입니다. 제가 맡은 프로젝트에서도 tailwindcss를 사용하고 있는데요. arbitrary의 calc 사용 중 공백을 이용한 가독성 증가를 원했습니다.

위와 같이 + 양옆에 공백을 주어 가독성을 높인 class를 작성하였습니다. (css에서도 operator 사용 시 문법적으로 공백이 필요하다고 합니다. 참고)

하지만 tailwind에서는 className의 공백을 기준으로 파싱을 하기 때문에 w-[calc(100px , +, 200px)] 와 같이 독립적으로 분리가 되었고 결국 적용 되지 않았습니다.

w-[calc(100px+200px)] 와 같이 공백을 제거해 문법에 맞게 작성하면 가장 단순한 해결 방식이지만 분명 저와 비슷한 불편함을 겪는 개발자가 있을 것이고 tailwindcss에 기여해보면 좋지 않을까 생각하여서 도전해보았습니다.

과정

먼저 tailwindcss의 git을 클론 받았습니다. 많은 파일이 존재하였는데요. 먼저 테스트 파일을 보면 독립적으로 실행되는 과정을 따라갈 수 있지 않을까? 생각하여 arbitrary에 해당하는 테스트 파일을 확인하였습니다.

tests/arbitrary-values.test.js


// tests/arbitrary-values.test.js
it('should support slashes in arbitrary modifiers', () => {
  let config = {
    content: [{ raw: html`` }],
  }

  return run('@tailwind utilities', config).then((result) => {
    return expect(result.css).toMatchFormattedCss(css`
      .text-lg\/\[calc\(50px\/1rem\)\] {
        font-size: 1.125rem;
        line-height: calc(50px / 1rem);
      }
    `)
  })
})

config 객체 안 content에 우리가 원하는 값들이 배열형태로 들어가는 것을 확인할 수 있습니다. 그럼 이 raw 안에 있는 class가 어떻게 파싱이 되어서 원하는 css로 변하게 될 수 있을까요? 아마 run을 실행하면 어떠한 함수가 실행이 되고 Promise를 리턴하는 것 같습니다. 이 run이 어떤 함수인지에 대해서 좀 더 살펴봅시다.

tests/util/run.js

//tests/util/run.js

export function run(input, config, plugin = tailwind) {
  let { currentTestName } = expect.getState()

  return postcss(plugin(config)).process(input, {
    from: `${path.resolve(__filename)}?test=${currentTestName}`,
  })
}

plugin 이라는 함수에 config가 인자로 들어가고 그 반환값을 postcss로 받아서 처리하는 군요. 일반적으로 postcss는 js의 스타일을 css로 변경해 주는 툴 입니다. 저희는 변환하기 전 calc 내부의 공백을 제거하는 것이 목적이므로 plugin 내부에서 해결책을 찾을 수 있을거라 추측할 수 있습니다.

src/plugin.js

// src/plugin.js

module.exports = function tailwindcss(configOrPath) {
  return {
    postcssPlugin: 'tailwindcss',
    plugins: [
      env.DEBUG &&
        function (root) {
          console.log('\n')
          console.time('JIT TOTAL')
          return root
        },
      async function (root, result) {
        // Use the path for the `@config` directive if it exists, otherwise use the
        // path for the file being processed
        configOrPath = findAtConfigPath(root, result) ?? configOrPath

        let context = setupTrackingContext(configOrPath)

        if (root.type === 'document') {
          let roots = root.nodes.filter((node) => node.type === 'root')

          for (const root of roots) {
            if (root.type === 'root') {
              await processTailwindFeatures(context)(root, result)
            }
          }

          return
        }

        await processTailwindFeatures(context)(root, result)
      },
      env.DEBUG &&
        function (root) {
          console.timeEnd('JIT TOTAL')
          console.log('\n')
          return root
        },
    ].filter(Boolean),
  }
}

이 부분을 해석하는데 조금 어려움이 있었는데요. 여기서는 plugins 배열을 반환하는데 그 안에는 여러 함수들이 존재합니다. 그 중 디버깅과는 관련없으니 제거를 하면 하나의 함수가 남겠군요. 저희는 Path와 관련된(url과 같은) config가 아니기에 configOrPath는 config와 같습니다.

이제 새로운 개념인 context가 나오는데요. 해당 부분을 hover해보면 다음과 같음을 알 수 있습니다.

context를 생성하는 함수를 반환하는 함수? 쯤으로 생각해도 좋을 것 같네요. 그럼 이 부분을 사용하는 processTailwindFeatures 을 찾아봅시다.

src/processTailwindFeatures.js

// src/processTailwindFeatures.js

export default function processTailwindFeatures(setupContext) {
  return async function (root, result) {
    let { tailwindDirectives, applyDirectives } = normalizeTailwindDirectives(root)

    // Partition apply rules that are found in the css
    // itself.
    partitionApplyAtRules()(root, result)

    let context = setupContext({
      tailwindDirectives,
      applyDirectives,
      registerDependency(dependency) {
        result.messages.push({
          plugin: 'tailwindcss',
          parent: result.opts.from,
          ...dependency,
        })
      },
      createContext(tailwindConfig, changedContent) {
        return createContext(tailwindConfig, changedContent, root)
      },
    })(root, result)
    if (context.tailwindConfig.separator === '-') {
      throw new Error(
        "The '-' character cannot be used as a custom separator in JIT mode due to parsing ambiguity. Please use another character like '_' instead."
      )
    }

    issueFlagNotices(context.tailwindConfig)

    await expandTailwindAtRules(context)(root, result)
    ...많은 함수
  }
}

꽤나 복잡한 함수인데요. 함수명으로 유추해보면 테일윈드 기능들을 처리하는 함수쯤으로 해석할 수 있습니다. 이곳에서 아까 의문점인 context을 사용하는데요. setupContext 로 props를 받아서 사용을 합니다. 그럼 이 context에는 어떠한 것이 있을까? 궁금하실텐데요. 해당 부분을 콘솔로 찍어보면 tailwind의 Config들, corePlugins, 유저로 부터 받은 커스텀 plugins, changedContent 등등 너무 많은 정보들이 context에 담겨있습니다. 여기서 가장 중요한 부분은 changedContent 인데요. 이 부분에는 저희가 처음에 넣었던 class관련 정보들이 들어있습니다.

changedContent: [
        {
          content: '',
          extension: 'html'
        }
      ],

그리고 expandTailwindAtRules 이 함수 실행 이후에는 changedContent 내부는 빈 배열이 되며, text-lg/[calc(50px/1rem)] 해당 클래스는 candidateRuleCache, classCache 등 context의 여러 프로퍼티에 들어가는 것을 알 수 있는데요. 이를 통해 expandTailwindAtRules 함수에서 어떠한 변환이 이루어 짐을 추측할 수 있습니다.

expandTailwindAtRules 부분도 꽤나 복잡한것 같지만 변수명이 직관적이기에 어떠한 역할을 하는 부분인지 짐작이 가능합니다. 전처리 부분을 제외한 핵심 부분을 보겠습니다.

src/lib/expandTailwindAtRules.js


// src/lib/expandTailwindAtRules.js
    let regexParserContent = []
    for (let item of context.changedContent) {
      let transformer = getTransformer(context.tailwindConfig, item.extension)
      let extractor = getExtractor(context, item.extension)
      regexParserContent.push([item, { transformer, extractor }])
    }

    const BATCH_SIZE = 500

    for (let i = 0; i < regexParserContent.length; i += BATCH_SIZE) {
      let batch = regexParserContent.slice(i, i + BATCH_SIZE)
      await Promise.all(
        batch.map(async ([{ file, content }, { transformer, extractor }]) => {
          content = file ? await fs.promises.readFile(file, 'utf8') : content
          getClassCandidates(transformer(content), extractor, candidates, seen)
        })
      )
    }

첫번째 for문에서는 아까 저희가 봤던 changedContent 프로퍼티에 접근하여 extension에 따른 변환 함수와 추출함수를 regexParserContent 배열에 넣어주고 있네요.

이후 두번째 for문에서 getClassCandidates 함수를 사용하고 있고 content를 감싸는 transformer 의 경우 builtInTransformers를 보면 svelt 일 경우 변환이 되는 구조라 저희는 content가 그대로 사용됩니다.

// Scans template contents for possible classes. This is a hot path on initial build but
// not too important for subsequent builds. The faster the better though — if we can speed
// up these regexes by 50% that could cut initial build time by like 20%.
function getClassCandidates(content, extractor, candidates, seen) {
  if (!extractorCache.has(extractor)) {
    extractorCache.set(extractor, new LRU({ maxSize: 25000 }))
  }
  for (let line of content.split('\n')) {
    line = line.trim()

    if (seen.has(line)) {
      continue
    }
    seen.add(line)

    if (extractorCache.get(extractor).has(line)) {
      for (let match of extractorCache.get(extractor).get(line)) {
        candidates.add(match)
      }
    } else {
      let extractorMatches = extractor(line).filter((s) => s !== '!*')
      let lineMatchesSet = new Set(extractorMatches)

      for (let match of lineMatchesSet) {
        candidates.add(match)
      }

      extractorCache.get(extractor).set(line, lineMatchesSet)
    }
  }
}

지금까지 잘 따라와 주셔서 감사합니다. 마지막 분석할 함수입니다. getClassCandidates 함수는 class가 될수있는 후보들을 뽑아내는 함수입니다. for문 내부에서는 content의 line별 split을 진행하고 해당 공백을 제거합니다. seen을 통해 이전에 추출을 했던 부분은 캐싱하는 작업까지 알 수 있습니다. 그 뒤 아래부분에서는 해당 Line을 추출하고 class 후보로 지정하는 함수임을 확인하였습니다.

저는 추출하기 전 calc 내부의 공백을 제거해주면 될것 같다고 판단하여 다음과 같은 함수를 작성하여 수정하였습니다.


function removeSpacesInsideCalc(content) {
  return content.replace(/calc\(([^)]*)\)/g, (_, p1) => `calc(${p1.replace(/\s+/g, '')})`)
}

function getClassCandidates(content, extractor, candidates, seen) {
  if (!extractorCache.has(extractor)) {
    extractorCache.set(extractor, new LRU({ maxSize: 25000 }))
  }
  for (let line of content.split('\n')) {
    line = line.trim()
    line = removeSpacesInsideCalc(line) // 해당 부분 추가

    ...
  }
}

이를 통해 class 후보를 확인하기 전 calc의 공백을 제거하여 하나의 클래스로 인식할 수 있게 하였고 테스트 코드를 작성하여 정상적으로 작동함을 확인하였습니다.

it('should support arbitrary calc values with spaces`', () => {
  let config = {
    content: [
      {
        raw: html``,
      },
    ],
  }

  return run('@tailwind utilities', config).then((result) => {
    expect(result.css).toMatchFormattedCss(css`
      .h-\[calc\(3rem-1rem\)\] {
        height: 2rem;
      }
      .w-\[calc\(100px\+200px\)\] {
        width: 300px;
      }
      .text-lg\/\[calc\(50px\/1rem\)\] {
        font-size: 1.125rem;
        line-height: calc(50px / 1rem);
      }
    `)
  })
})

후기

결론적으로는 reject 당했습니다 ㅎㅎ... tailwind 컨트리뷰터분이 친절하게 피드백을 주셨는데요! 결론적으로는 공백으로 클래스를 구분하는 것은 html 고유의 특성이므로 수정해서는 안되는것 같아요.

한편으로는 아쉬움이 많이 남지만 해당 과정에서 tailwind의 동작과정을 짧게나마 알아볼 수 있었고 유명한 개발자와 소통을 해볼 수 있었다는 뿌듯함이 있었던것 같습니다. 또한 해당 부분의 이슈들을 찾아보다 보니 자연스럽게 영어도 늘 수 있어서 재밌었습니다!

Link의 prefetch를 까보자

Sun, 31 Mar 2024 04:54:41 GMT

NextJS 환경에서 개발하다 보면 Link 컴포넌트를 사용하지 않을 수 없는데요. 프로젝트를 진행하다가 Link 태그에 hover시 무한렌더링이 발생하는 이슈를 겪었습니다. 그런데 참 이상하게 개발환경에서는 발생하지 않지만 배포환경에서만 발생을 하였습니다. 해당 이슈 해결과정을 적어보려고 합니다.

문제 상황

문제 상황은 아주 간단합니다. App router 개발 환경에서 Link 버튼을 클릭하면 정상적으로 라우팅이 되었지만, 막상 배포환경에서는 Link 컴포넌트 hover시에 페이지 전체가 계속해서 무한 렌더링이 발생하였습니다. 처음에는 어떻게 프론트 단에서 개발환경과 배포환경이 다를수가 있지? 라는 충격과 함께 디버깅을 위해 매번 배포하는 멍청한 짓을 했습니다.

next build -> next start

문제 해결을 하기 전 prodction 환경을 테스팅 하기에 매번 배포를 하는것은 시간비용이 엄청나게 낭비된다고 생각했습니다. 분명 배포 환경을 테스팅 하는 법이 있을것이라고 생각하여 찾아보니 공식문서에서 다음과 같이 친절하게 적혀있었습니다.

매번 무의식적으로 NextJS를 개발을 위해 npm run dev 명령어를 통해 해당 뜻도 모르고 개발했던것을 반성하며 한 도구를 사용하는 것에 대해 정확히 알고 있는가? 에 대해 다시 생각해 보았습니다.

문제 원인

프로젝트에 전역상태(jotai), react-query, tanstack table 등등 너무 많은 라이브러리들이 의존되어 있어 문제의 원인을 찾기가 어려웠습니다. 계속해서 검색을 해보며 Link 와 production 환경의 키워드로 Link 태그의 prefetch 속성이 있다는 것을 알았습니다.

Prefetch

Link 태그에는 prefetch 라는 속성이 있습니다. 이 속성은 말 그대로 Link태그의 href에 해당 사이트의 데이터를 미리 받아오는것입니다. 왜 미리 받아올까요?

NextJs는 Client side render 방식처럼 한번에 모든 데이터를 받아오는 방식과 다르게 Page 별 데이터를 요청할 때 마다 받아오는 방식입니다. 그러다 보니 유저가 페이지 라우팅을 위해 Link를 클릭 한 후 데이터를 받아오게 되면, 데이터가 클 경우 유저는 오래 기다리게 되어 좋지않은 UX를 제공합니다.

이를 개선하기 위해 NextJS는 유저의 Viewport에 해당하는 Link들은 이동할 가능성이 있다고 판단하여 미리 데이터를 받아놓습니다. 기본적으로 App router에서 prefetch는 null로 설정되어 있고 이는 static routes의 경우 모든데이터를, dynamic routes의 경우 loading.js boundary의 가장 가까운 세그먼트를 다운받게 된다고 합니다.

해결

정확한 원인은 모르겠지만 환경에 따라 영향을 받는것은 prefetch 기능이니 기능을 false로 변경하여 정상적으로 무한렌더링이 해결되었습니다. 하지만 매우 찝찝합니다. prefetch기능은 분명 viewport와 관련이 있는것이였고 그럼 hover가 아닌 Link가 viewport에 들어온 시점부터 무한 렌더링이 발생해야 하는것이 아닌가? 또한, 왜 무한렌더링이 발생하는것일까? 에 대해서 궁금증이 남아있었습니다.

그럼 hover와 무슨 상관?

Link hover와 관련된 게시글을 몇몇 찾아보니 다음과 같이 false일경우에도 hover 경우에는 작동한다고 하였습니다.

공식 문서에 있는 설명인데, 기본값(true )일 경우 브라우저의 Viewport 내에 있으면 Link의 경로에 해당하는 페이지를 백그라운드에서 미리 가져오는 역할을 한다고 한다. 근데 이 기능은 false 일 때도 완전히 꺼지는 것은 아니고 링크를 hover하면 로딩한다고 한다. - 출처 : Web: Next.js Link와 Prefetch 과정 파헤쳐보기 , 공식문서

매우 이상합니다. 이 논리대로면 prefetch 기능을 false로 변경하더라도 hover시에는 완전히 꺼지지 않으므로 계속해서 무한렌더링이 발생해야하는데요. 여기서 위 게시글을 작성자 처럼 NextJS 의 Link 태그를 까보기로 결정합니다.

// tag v14.1.2
// https://github.com/vercel/next.js/blob/f564deef86be32a6b25125ddb8172c7c27d3f19a/packages/next/src/client/link.tsx#L638

     onMouseEnter(e) {
        if (!legacyBehavior && typeof onMouseEnterProp === 'function') {
          onMouseEnterProp(e)
        }

        if (
          legacyBehavior &&
          child.props &&
          typeof child.props.onMouseEnter === 'function'
        ) {
          child.props.onMouseEnter(e)
        }

        if (!router) {
          return
        }

       // 이곳을 주목!!!
        if (
          (!prefetchEnabled || process.env.NODE_ENV === 'development') &&
          isAppRouter
        ) {
          return
        }

        prefetch(
          router,
          href,
          as,
          {
            locale,
            priority: true,
            // @see {https://github.com/vercel/next.js/discussions/40268?sort=top#discussioncomment-3572642}
            bypassPrefetchedCheck: true,
          },
          {
            kind: appPrefetchKind,
          },
          isAppRouter
        )
      },

위 코드는 NextJs의 Link 컴포넌트 구현 중 onMouseEnter(hover) 이벤트 발생 시 작동하는 로직입니다. 그중 제가 주석을 달아 놓은 부분의 조건문을 확인해보면 prefetch 조건을 끄고 App router이면 return을 발생시킵니다. 결국, prefetch기능이 false이더라도 hover시 작동하는 것은 Page Rotuer일 경우였고 App router의 경우는 발생하지 않는다고 합니다.

몇몇 스택오버플로우에서는 Prefetch를 껐는데도 hover할때 자꾸 발생한다며 불만이 있어서 그런것 같습니다.

hover가 아닌 Link가 viewport에 들어온 시점부터 무한 렌더링이 발생해야 하는것이 아닌가?

그래도 우리는 이것에 대한 해답을 찾지 못했습니다. 문득 이런생각이 들었습니다.

viewport에 들어왔을때 발생하는 prefetch와 hover시에 발생하는 prefetch의 종류가 다른가?

그래서 다시 오픈소스를 뜯어보기로 하였습니다.

// https://github.com/vercel/next.js/blob/f564deef86be32a6b25125ddb8172c7c27d3f19a/packages/next/src/client/link.tsx#L551

    React.useEffect(() => {
      // in dev, we only prefetch on hover to avoid wasting resources as the prefetch will trigger compiling the page.
      if (process.env.NODE_ENV !== 'production') {
        return
      }

      if (!router) {
        return
      }

      // If we don't need to prefetch the URL, don't do prefetch.
      if (!isVisible || !prefetchEnabled) {
        return
      }

      // Prefetch the URL.
      prefetch(
        router,
        href,
        as,
        { locale },
        {
          kind: appPrefetchKind,
        },
        isAppRouter
      )
    }, [
      as,
      href,
      isVisible,
      locale,
      prefetchEnabled,
      pagesRouter?.locale,
      router,
      isAppRouter,
      appPrefetchKind,
    ])

이 코드는 viewport에 들어왔을때 prefetch가 실행되는 코드 입니다. 그럼 위의 onMouseEnter과 어떤 차이가 있는지 비교해보면 한가지 차이가 있습니다.

// viewport의 prefetch
prefetch(
  router,
  href,
  as,
  { locale },
  {
    kind: appPrefetchKind,
  },
  isAppRouter,
);


//onMouseEnter의 prefetch
prefetch(
  router,
  href,
  as,
  {
    locale,
    priority: true,
    // @see {https://github.com/vercel/next.js/discussions/40268?sort=top#discussioncomment-3572642}
    bypassPrefetchedCheck: true,
  },
  {
    kind: appPrefetchKind,
  },
  isAppRouter,
);

여기서 차이점은 옵션으로 priority와 bypassPrefetchedCheck 인데요. 우선 bypassPrefetchedCheck의 경우 위 주석을 들어가보면 hover할떄마다 prefetch를 해서 캐시를 하기위해 준 옵션 같습니다.

그럼 priority가 하는 역할을 따라가 봅시다. ~~(제발 이것이 해답이길....)~~ prefetch의 정의된 함수를 보면 다음과 같습니다.

// https://github.com/vercel/next.js/blob/f564deef86be32a6b25125ddb8172c7c27d3f19a/packages/next/src/client/link.tsx#L124

import type {
  NextRouter,
  PrefetchOptions as RouterPrefetchOptions,
} from '../shared/lib/router/router'

type PrefetchOptions = RouterPrefetchOptions & {
  /**
   * bypassPrefetchedCheck will bypass the check to see if the `href` has
   * already been fetched.
   */
  bypassPrefetchedCheck?: boolean
}

function prefetch(
  router: NextRouter | AppRouterInstance,
  href: string,
  as: string,
  options: PrefetchOptions,
  appOptions: AppRouterPrefetchOptions,
  isAppRouter: boolean
): void {
// ... 불필요한 것 생략
  const prefetchPromise = isAppRouter
    ? (router as AppRouterInstance).prefetch(href, appOptions)
    : (router as NextRouter).prefetch(href, as, options)

}

엥? AppRouter의 경우에는 options를 사용하지 않네? 그럼 priority는 상관없는 것 이였구나...

이때부터 방향을 잃어서 아쉽게도 원인을 찾지 못했습니다... 허무하셨다면 죄송합니다.. 😭 하지만 여기서 끝내기에는 아쉬우니 priority가 하는 역할이 무엇인지 찾아봅시다!

prefetch의 priority option (Page router)

먼저 router에서 prefetch의 프로퍼티에 접근하여 호출하는것 같으므로 router를 찾아봅시다.

//https://github.com/vercel/next.js/blob/f564deef86be32a6b25125ddb8172c7c27d3f19a/packages/next/src/client/link.tsx#L260C1-L292C44
import { RouterContext } from '../shared/lib/router-context.shared-runtime'
const Link = React.forwardRef(
  function LinkComponent(props, forwardedRef) {
    // ... 생략

    const pagesRouter = React.useContext(RouterContext)
    const appRouter = React.useContext(AppRouterContext)
    const router = pagesRouter ?? appRouter

router는 LinkComponent에서 선언이 되어 있었고 RouterContext를 통해 받아옴을 알 수 있었습니다.

// '../shared/lib/router-context.shared-runtime'
export const RouterContext = React.createContext(null)

// https://github.com/vercel/next.js/blob/1c5aa7fa09cc5503c621c534fc40065cbd2aefcb/packages/next/src/client/index.tsx#L321C14-L332C40


  
    
      {children}
    
  
;

../shared/lib/router-context.shared-runtime 경로에는 단순 RouterContext 를 선언한 곳이였고 해당 Context의 value는 Provider에 makePublicRouterInstance(router)를 통해 주입하고있었습니다.

//https://github.com/vercel/next.js/blob/1c5aa7fa09cc5503c621c534fc40065cbd2aefcb/packages/next/src/client/router.ts#L169
export function makePublicRouterInstance(router: Router): NextRouter {
 // ...생략

  return instance
}

정확하게 makePublicRouterInstance 함수의 내부 로직은 이해하지 못했지만 React의 Router를 props로 받아 NextRouter로 변환해서 반환하는 함수로 추론했습니다.

//https://github.com/vercel/next.js/blob/4efe14238b5ab11935e73aa09631ef5ec8045b13/packages/next/src/shared/lib/router/router.ts#L355

export type NextRouter = BaseRouter &
  Pick<
    Router,
    | 'push'
    | 'replace'
    | 'reload'
    | 'back'
    | 'forward'
    | 'prefetch'
    | 'beforePopState'
    | 'events'
    | 'isFallback'
    | 'isReady'
    | 'isPreview'
  >

  //https://github.com/vercel/next.js/blob/4efe14238b5ab11935e73aa09631ef5ec8045b13/packages/next/src/shared/lib/router/router.ts#L2283

 async prefetch(
    url: string,
    asPath: string = url,
    options: PrefetchOptions = {}
  ): Promise {
    // Prefetch is not supported in development mode because it would trigger on-demand-entries
    if (process.env.NODE_ENV !== 'production') {
      return

     //생략

        await Promise.all([
      this.pageLoader._isSsg(route).then((isSsg) => {
        return isSsg
          ? fetchNextData({
              dataHref: data?.json
                ? data?.dataHref
                : this.pageLoader.getDataHref({
                    href: url,
                    asPath: resolvedAs,
                    locale: locale,
                  }),
              isServerRender: false,
              parseJSON: true,
              inflightCache: this.sdc,
              persistCache: !this.isPreview,
              isPrefetch: true,
              unstable_skipClientCache:
                options.unstable_skipClientCache ||
                (options.priority &&
                  !!process.env.__NEXT_OPTIMISTIC_CLIENT_CACHE),
            })
              .then(() => false)
              .catch(() => false)
          : false
      }),
      this.pageLoader[options.priority ? 'loadPage' : 'prefetch'](route),
    ])
}}

NextRouter 타입이 선언된 곳으로 찾아보니 prefetch라는 속성을 가지고 있었고, 해당 함수를 선언한 곳을 보니 마지막 줄에 option.priority의 여부에 따라 loadPage와 prefetch를 나눠서 적용하는 것을 확인할 수 있었습니다.

이후, pageLoader가 어떤역할을 하는지 분석해야 할 양이 방대하여 여기까지 마무리 하였습니다.

정리

App router 환경에서 Link 컴포넌트에 hover시 무한렌더링이 발생하는 이슈 발생
prefetch 기능 작동을 off하여 문제 해결
prefetch는 page router와 app router의 작동 방식이 조금 다름
prefetch 작동 방식을 Next 코드를 까보며 동작 방식을 이해

해당 이슈를 정확하게 재연하기가 힘들어 원인 분석이 명확하게 못해서 아쉬움이 많이 남습니다. 해결책은 알지만 왜 해당 이슈의 해결책인지 정확하게 알지 못해 찝찝함이 남지만 NextJS의 prefetch의 작동방식을 공식문서에 담지못한 부분까지 찾아보았다는 점은 흥미로웠습니다! 혹시 잘못된 부분이나 원인을 알고계시면 댓글로 알려주시면 감사하겠습니다. 읽어주셔서 감사합니다🙇🏻‍♂️

useState 의 state 는 어떤 코드로 쓰여있나?! - 정리

Thu, 07 Mar 2024 15:32:07 GMT

useState 완전분석(feat. Linked list)

// react/packages/react-reconciler/src/ReactFiberHooks.js
// 926번 줄

function mountWorkInProgressHook(): Hook {
  const hook: Hook = {
    memoizedState: null,

    baseState: null,
    baseQueue: null,
    queue: null,

    next: null,
  };

    // 만약 Hook이 없으면 첫번째 값을 할당
  if (workInProgressHook === null) {
    // This is the first hook in the list
    currentlyRenderingFiber.memoizedState = workInProgressHook = hook;
  } else {
    // workInProgress를 한칸 옆으로 이동시킴
    workInProgressHook = workInProgressHook.next = hook;
  }
  return workInProgressHook;
}

memoizedState 는 상태가 변한 후 최종적으로 기억되는 값

next 는 링크드리스트 처럼 연결되어 있다. 이 값은 다음 훅을 할당될 키값 이다.
fiber는 hook이 링크드리스트로 연결되어 있다.

mountStateImpl

//1750 줄
function mountStateImpl(initialState: (() => S) | S): Hook {
  const hook = mountWorkInProgressHook(); // 여기서 hook을 넘겨줌
  if (typeof initialState === 'function') {
    const initialStateInitializer = initialState;
    // $FlowFixMe[incompatible-use]: Flow doesn't like mixed types
    initialState = initialStateInitializer();
    if (shouldDoubleInvokeUserFnsInHooksDEV) {
      setIsStrictModeForDevtools(true);
      // $FlowFixMe[incompatible-use]: Flow doesn't like mixed types
      initialStateInitializer();
      setIsStrictModeForDevtools(false);
    }
  }
  hook.memoizedState = hook.baseState = initialState;
  const queue: UpdateQueue> = {
    pending: null,
    lanes: NoLanes,
    dispatch: null,
    lastRenderedReducer: basicStateReducer,
    lastRenderedState: (initialState: any),
  };
  hook.queue = queue;
  return hook;
}

이곳에서 initialState가 함수이면 함수를 실행시킨 값을 전달함을 알 수 있다.

Hook에서 왜 queue 객체를 사용할까?

const queue: UpdateQueue> = { pending: null, lanes: NoLanes, dispatch: null, lastRenderedReducer: basicStateReducer, lastRenderedState: (initialState: any), };

pending은 업데이트 될 다음 상태를 나타낸다.

dispatch는 queue에서 추가로 들어갈 수 있도록 도와주는 것

function mountState( initialState: (() => S) | S, ): [S, Dispatch>] { const hook = mountStateImpl(initialState); const queue = hook.queue; const dispatch: Dispatch> = (dispatchSetState.bind( null, currentlyRenderingFiber, queue, ): any); queue.dispatch = dispatch; return [hook.memoizedState, dispatch]; }

dispatch는 이전에 선언했던 queue가 바인딩 되고 있다.

이 dispatch는 외부로 노출되고 있다. → 이것이 결론적으로 setState

renderWithHooks 함수? useState 를 할당하는 과정 코드 까보기?! - 정리

Tue, 05 Mar 2024 12:07:21 GMT

유튜브에 React 까보기 시리즈 라는 영상으로 스터디를 진행하며 의미있는 강의는 자주 정리해 보려고 합니다. 강의를 찍으신 시점과 제가 학습하는 시점에 차이가 발생해 React 라이브러리의 코드가 다소 변화되었습니다. 이 글을 읽는 시점에도 코드가 다를 수 있음을 알려 드립니다.

어떻게 useState를 export 하는가

//react/packages/react-reconciler/src/ReactFiberHooks.js //159번줄 const {ReactCurrentDispatcher, ReactCurrentBatchConfig} = ReactSharedInternals;

먼저 ReactCurrentDispatcher.current에 할당을 해야함

이 할당은 renderWithHooks 함수에서 조건에 따라 HooksDispatcherOnMount 와 HooksDispatcherOnUpdate 이 결정된다.

//react/packages/react-reconciler/src/ReactFiberHooks.js //476번줄 export function renderWithHooks( ... if (__DEV__) { if (current !== null && current.memoizedState !== null) { ReactCurrentDispatcher.current = HooksDispatcherOnUpdateInDEV; } else if (hookTypesDev !== null) { // This dispatcher handles an edge case where a component is updating, // but no stateful hooks have been used. // We want to match the production code behavior (which will use HooksDispatcherOnMount), // but with the extra DEV validation to ensure hooks ordering hasn't changed. // This dispatcher does that. ReactCurrentDispatcher.current = HooksDispatcherOnMountWithHookTypesInDEV; } else { ReactCurrentDispatcher.current = HooksDispatcherOnMountInDEV; } } else { ReactCurrentDispatcher.current = current === null || current.memoizedState === null ? HooksDispatcherOnMount : HooksDispatcherOnUpdate; }

current === null || current.memoizedState === null 이 된다면 Mount 해야하며, 아닐경우 Update 일경우로 생각

강의랑 다름 강의에선 nextCurrentHook으로 나옴 → 결국 Mount 하냐 Update 하냐의 결정은 current가 Dom에 반영 여부로 확인

그럼 HooksDispatcherOnMount 안에 뭐가 있나?

useState 가 안에 존재

//react/packages/react-reconciler/src/ReactFiberHooks.js //3470번줄 const HooksDispatcherOnMount: Dispatcher = { readContext, use, useCallback: mountCallback, useContext: readContext, useEffect: mountEffect, useImperativeHandle: mountImperativeHandle, useLayoutEffect: mountLayoutEffect, useInsertionEffect: mountInsertionEffect, useMemo: mountMemo, useReducer: mountReducer, useRef: mountRef, useState: mountState, useDebugValue: mountDebugValue, useDeferredValue: mountDeferredValue, useTransition: mountTransition, useSyncExternalStore: mountSyncExternalStore, useId: mountId, }; const HooksDispatcherOnUpdate: Dispatcher = { readContext, use, useCallback: updateCallback, useContext: readContext, useEffect: updateEffect, useImperativeHandle: updateImperativeHandle, useInsertionEffect: updateInsertionEffect, useLayoutEffect: updateLayoutEffect, useMemo: updateMemo, useReducer: updateReducer, useRef: updateRef, useState: updateState, useDebugValue: updateDebugValue, useDeferredValue: updateDeferredValue, useTransition: updateTransition, useSyncExternalStore: updateSyncExternalStore, useId: updateId, };

Update 함수에는 updateState가 들어간다.

renderWithHooks

renderWithHooks() → hook과 함께 render 즉, hook을 주입하는 역할을 한다

//react/packages/react-reconciler/src/ReactFiberHooks.js //476번줄 export function renderWithHooks( current: Fiber | null, workInProgress: Fiber ... ): any { renderLanes = nextRenderLanes; **currentlyRenderingFiber = workInProgress; <- 이 코드가 핵심**

이 사진에서 WorkInProgress 작업물을 Current에 주입하는 역할

NextcurrentHook

강의의 코드와 다른점 존재. nextCurrentHook은 더이상 renderWithHooks에서 사용하지 않고 updateWorkInProgressHook 함수에서 사용

이에 따라 돔에 반영되어있는지 아닌지 확인하는 조건은 === null || current.memoizedState === null 로 대체된다.

이 memoizedState는 Hook이 들어있음을 추측

renderWithHooks의 다른 역할은 컴포넌트를 호출한다.

// 572번 let children = Component(props, secondArg); // **업데이트 정보를 스케쥴러와 패키지에게 전달 했음?을 확인 -> Mount 일경우는 false** if (didScheduleRenderPhaseUpdateDuringThisPass) { // Keep rendering until the component stabilizes (there are no more render // phase updates). children = renderWithHooksAgain( workInProgress, Component, props, secondArg, ); }

// 607번 function finishRenderingHooks( current: Fiber | null, workInProgress: Fiber, Component: (p: Props, arg: SecondArg) => any, ): void { // **이것을 왜?** ReactCurrentDispatcher.current = ContextOnlyDispatcher; const didRenderTooFewHooks = currentHook !== null && currentHook.next !== null; renderLanes = NoLanes; currentlyRenderingFiber = (null: any); currentHook = null; workInProgressHook = null;

ReactCurrentDispatcher.current = ContextOnlyDispatcher; 이 코드가 의미하는 것은 ReactCurrentDispatcher.current를 재할당 하는 것이 아니라 위에서 컴포넌트를 호출한 뒤 더 이상 Hook을 요청해서는 안될때 Error를 알려주기 위함을 의미

//3432번줄 export const ContextOnlyDispatcher: Dispatcher = { readContext, use, useCallback: throwInvalidHookError, useContext: throwInvalidHookError, useEffect: throwInvalidHookError, useImperativeHandle: throwInvalidHookError, useInsertionEffect: throwInvalidHookError, useLayoutEffect: throwInvalidHookError, useMemo: throwInvalidHookError, useReducer: throwInvalidHookError, useRef: throwInvalidHookError, useState: throwInvalidHookError, useDebugValue: throwInvalidHookError, useDeferredValue: throwInvalidHookError, useTransition: throwInvalidHookError, useSyncExternalStore: throwInvalidHookError, useId: throwInvalidHookError, }; function throwInvalidHookError() { throw new Error( 'Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for' + ' one of the following reasons:\n' + '1. You might have mismatching versions of React and the renderer (such as React DOM)\n' + '2. You might be breaking the Rules of Hooks\n' + '3. You might have more than one copy of React in the same app\n' + 'See https://react.dev/link/invalid-hook-call for tips about how to debug and fix this problem.', ); }

이 코드를 보면 useState에 Error를 던지는 것을 할 수 있음

// 926번줄 function mountWorkInProgressHook(): Hook { const hook: Hook = { memoizedState: null, baseState: null, baseQueue: null, queue: null, next: null, }; if (workInProgressHook === null) { // This is the first hook in the list currentlyRenderingFiber.memoizedState = workInProgressHook = hook; } else { // Append to the end of the list workInProgressHook = workInProgressHook.next = hook; } return workInProgressHook; }

이 코드는 memoizedState에 hook이 대입되는 것을 알 수 있음

이 코드는 Mount State 에서 불린다.

// 1750번 function mountStateImpl(initialState: (() => S) | S): Hook { const hook = mountWorkInProgressHook(); if (typeof initialState === 'function') { const initialStateInitializer = initialState; // $FlowFixMe[incompatible-use]: Flow doesn't like mixed types initialState = initialStateInitializer(); if (shouldDoubleInvokeUserFnsInHooksDEV) { setIsStrictModeForDevtools(true); // $FlowFixMe[incompatible-use]: Flow doesn't like mixed types initialStateInitializer(); setIsStrictModeForDevtools(false); } } hook.memoizedState = hook.baseState = initialState; const queue: UpdateQueue> = { pending: null, lanes: NoLanes, dispatch: null, lastRenderedReducer: basicStateReducer, lastRenderedState: (initialState: any), }; hook.queue = queue; return hook; } function mountState( initialState: (() => S) | S, ): [S, Dispatch>] { const hook = mountStateImpl(initialState); const queue = hook.queue; const dispatch: Dispatch> = (dispatchSetState.bind( null, currentlyRenderingFiber, queue, ): any); queue.dispatch = dispatch; return [hook.memoizedState, dispatch]; }

Reconciler는 Fiber에 Hook 정보를 담아주는 역할을 한다.

///607 번줄 function finishRenderingHooks( current: Fiber | null, workInProgress: Fiber, Component: (p: Props, arg: SecondArg) => any, ): void { if (__DEV__) { workInProgress._debugHookTypes = hookTypesDev; } // We can assume the previous dispatcher is always this one, since we set it // at the beginning of the render phase and there's no re-entrance. ReactCurrentDispatcher.current = ContextOnlyDispatcher; // This check uses currentHook so that it works the same in DEV and prod bundles. // hookTypesDev could catch more cases (e.g. context) but only in DEV bundles. const didRenderTooFewHooks = currentHook !== null && currentHook.next !== null; renderLanes = NoLanes; currentlyRenderingFiber = (null: any); currentHook = null; workInProgressHook = null;

이곳에서 null로 초기화를 하는 이유는 이 Hook들은 전역으로 사용하고 있기 때문에 다른 컴포넌트들도 사용될 수 있어 초기화를 진행

CSS 라이브러리들의 특징

Sat, 20 Jan 2024 04:15:37 GMT

요즘에는 정말 다양한 스타일을 위한 라이브러리가 많습니다. 저 또한 개발을 하면서 그 당시 인기있는 라이브러리를 따라 사용해 왔습니다.. Styled Component -> Sass -> ChakraUI -> tailwindcss (현재 가장 많이 쓰고있음) 하지만 이 라이브러리 별 동작 과정을 정확하게 이해하고 있나 의구심이 들어 이 기회에 각 특징을 정리해보려고 합니다. 특히 빌드, 런타임 시점 위주로 정리를 해보겠습니다.

.CSS 파일

가장 근본이며 순정인 css 파일부터 정리를 해봅시다. 우리가 프론트엔드를 가장 먼저 시작할때 html 다음으로 배우는 스타일을 위한 언어입니다. 사용방법으로는 3가지가 있습니다.

내부 스타일 시트

외부 스타일 시트

인라인 스타일

동작 방식

그럼 이 CSS 파일은 어떻게 적용이 될까요? 먼저 로컬에 html, css 파일이 있고 html을 실행시키면 다음과 같은 방식으로 painting이 됩니다.

결국 우리는 .CSS 파일을 사용할 떄는 정적으로 파싱이 되어 DOM에 적용 된다고 생각하면 됩니다. 만약 동적으로 스타일을 바꾸고 싶을경우에는 JS를 이용하여 바꾸어 주어야 합니다.

Sass

Sass is a stylesheet language that’s compiled to CSS. It allows you to use variables, nested rules, mixins, functions, and more, all with a fully CSS-compatible syntax. Sass helps keep large stylesheets well-organized and makes it easy to share design within and across projects. 출처 : Sass

Sass에서 말했듯 전처리기를 통해 다양한 기능 Ex) 변수, 중첩규칙, mixins, 함수 등등 을 통해 좀 더 빠르고 효율적으로 개발을 할 수 있습니다. 밑에서 다룰 CSS in JS 보다 훨씬 빠를 수 밖에 없죠.

참고로 Sass와 Scss의 차이는 문법이 살짝 다른것 같습니다. 두 문법 다 Sass 라이브러리에서 사용할 수 있지만 대체적으로 Scss 문법이 좀 더 css에 가까워 익숙합니다.

Sass

Scss

CSS Module

웹이 점점 더 복잡해지면서 프론트엔드 세계에는 리액트 프레임워크가 등장하게 되었습니다. 그럼으로써 고유한 클래스 명을 관리하기가 비용이 너무 많이 들어 그에 따라 .CSS의 단점을 보완하고자 CSS Module이 등장하였습니다.

CSS Module의 사용방법은 간단합니다. [파일이름].module.css 로 작성을 한뒤 원하는 곳에서 import를 하면 되기 때문입니다. 그럼 어떻게 .CSS 의 단점을 보완할 수 있었을까요?

CSS Module 컴파일러

React 컴포넌트에서 해당 CSS 파일을 불러올 때 선언된 CSS 클래스명은 모두 고유한 이름으로 자동 변환됩니다. 고유한 클래스명은 파일 경로, 파일 이름, 원래 작성한 클래스명, 해쉬값 등을 사용하여 자동 생성됩니다. 따라서 CSS Module을 사용하면 CSS 파일마다 고유한 네임스페이스를 자동으로 부여해 주기 때문에 각각의 React 컴포넌트는 완전히 분리된 스타일을 보장받게 됩니다. 출처 : TCP School

리액트는 정말 똑똑하다고 생각합니다... 해당 컴포넌트에 필요한 CSS Module이 있으면 그 모듈은 컴파일러를 통해 고유의 className으로 변경되고 css파일과 js파일로 변경이 됩니다. 이를 통해 Css 의 단점을 보완할 수 있습니다.

CSS in JS

최신 스타일 라이브러리 추세

점점 더 프로젝트의 규모가 커지면서 css를 모듈로 관리하기에는 힘들어졌습니다. 그래서 CSS in JS라는 방법이 생겼는데요. 이는 css 구문을 js파일에서 관리하자! 입니다. 이로 인해 스타일이 지역스코프, 스타일을 해당 컴포넌트 파일에서 작성, JS 변수 사용 가능 등등 정말 많은 장점이 있습니다. 하지만 그에따른 단점도 존재하겠죠?

Styled-component

먼저 Styled-component 의 경우 CSR이 유행할 당시에 많이 사용하였습니다. Styled-component는 빌드타임이 아닌 런타임에 스타일을 해석하기에 렌더링이 느려질 수 있습니다. 특히 요즘 SSR이 유행하기에 런타임에 스타일을 붙이는 방식은 추천하지 않습니다.

tailwindcss

tailwindcss는 CSS in JS 방식이지만 런타임에 스타일을 해석하는 방식과 조금 다릅니다. 라이브러리 내부에는 미리 css 파일이 정리되어 있으며 개발자는 컴포넌트의 className에 css를 입력하여 적용하는 방식입니다. 이를 통해 빌드 타임에 css 파일로 변환될 수 있습니다.

간혹가다 bg-red-${prop} 과 같이 작성하였을때 적용이 안되는 경우가 있는데 이는 tailwind가 빌드 타임시에 잘못된 css 작성이나 적용되지 않는 부분은 알아서 삭제되기에 올바른 방식이 아니라고 할 수 있습니다.

zero runtime css in JS

css in js 중 styled component는 런타임에 빌드가 될 경우 painting이 느려질 수 있다고 말씀 드렸는데요. 이를 해결하기 위해 zero runtime css in js가 나왔습니다. 이는 스타일을 js에서 동적으로 받을 수 있지만 이를 미리 빌드타임때 css 파일로 컴파일 되어 zero time에 사용할 수 있습니다.

대표적으로는 vanilla extract가 있습니다.

useQuery을 넘어 useMutation 사용

Mon, 01 Jan 2024 07:50:13 GMT

문제상황

게시글의 댓글 작성 기능을 구현하고 있었습니다. 사용자가 현재 게시글에 댓글 등록 버튼을 누른 후, 새로고침을 해야만 새로운 댓글 정보를 서버로 부터 받아오는 문제가 발생하였습니다. 댓글 정보는 react query를 통해서 관리하고 있었기에 어떠한 방식으로 문제를 해결하고 개선하였는지 작성해보려 합니다.

react query 란?

TanStack Query 에 따르면

React Query는 종종 React에 없는 data-fetching 라이브러리로 되지만, 좀 더 기술적인 용어로 표현하자면 React 애플리케이션에서 서버 상태를 불러오고, 캐싱하고, 동기화하고, 업데이트하는 작업을 쉽게 해줍니다.

v4 부터 TanStack팀은 react 보다 좀 더 다양한 프레임워크에게 기능을 제공하여 react query대신 TanStack Query라는 표현을 사용하는것 같습니다.

이 라이브러리를 사용하는 이유

reDuck팀은 react query를 통해 로컬 데이터와 서버 데이터(게시글, 댓글) 로직을 분리하여 관리하기 위해 사용합니다. 또한, 서버 데이터를 캐싱하면서 서버에 데이터 요청 횟수를 최적화 할 수 있다는 장점이 있습니다.

문제의 원인

현재 댓글 상태 관리 flow는 다음과 같습니다.

get 요청을 통해 현재 게시글의 댓글 list 들을 불러온다.

post 요청을 통해 현재 게시글에 댓글을 추가한다.

새 댓글을 렌더링 하기 위해 1번을 다시 시작한다.

여기서 문제의 원인은 3번입니다. react-query에서는 서버의 상태(댓글 리스트)가 변했는지 알지 못하기에 개발자가 직접 알려주어야 합니다. 그러기 위해서 useQuery의 refetch 기능을 이용하여 post 요청 시 댓글 리스트 get 요청을 다시 하기로 하였습니다.

refetch를 이용한 코드

//ComentList.tsx function ComentList() { const { data, refetch } = useQuery({ queryKey: ['commentList'], queryFn: async () => await postManager.getPost(), }); const comments = data?.comments return ( <> {comments?.map((comment: IComment) => ( ))} ); } //CommentUploadButton.tsx function CommentUploadButton({refetch}) { const handleComment = async (content: string) => { await commentManager.createComment(content); refetch(); }; return ; }

댓글 리스트가 필요한 컴포넌트에서 useQuery 훅을 사용하여 서버로 부터 데이터를 받고, 댓글 업로드 버튼에 Props 로 refetch를 전달하여 댓글 작성 완료 후 refetch를 실행하여 새로운 데이터를 렌더링 하였습니다.

refetch의 아쉬운 점과 개선

이러한 방식으로 해결은 하였지만 깔끔하게 해결된 느낌을 받지 못했습니다. 컴포넌트가 좀 더 복잡해지면 props drilling이 발생할 수 있고 refech를 해야하는 모든 경우에 메소드를 한번씩 적어야 하기 때문입니다.

useMutation을 사용하자.

공식문서에 따르면 데이터를 Get 요청할때에는 useQuery를 그 외(post,put,delete)의 경우는 useMutation을 권장합니다. useMutation 훅에서 제공되는 다양한 기능을 통해 좀 더 현명하게 데이터를 다룰 수 있습니다.

저는 여기서 댓글 작성 성공 시 기존 댓글 작성의 cache가 더이상 유효하지 않다고 알리고 데이터를 다시 받아오려고 합니다.

useMutation를 이용한 코드

//ComentList.tsx function ComentList() { const { data } = useQuery({ queryKey: ['commentList'], queryFn: async () => await postManager.getPost(), }); const comments = data?.comments return ( <> {comments?.map((comment: IComment) => ( ))} ); } //CommentUploadButton.tsx function CommentUploadButton() { const queryClient = useQueryClient(); const { mutate } = useMutation({ mutationFn: (content: string) => commentManager.createComment({ content}), onSuccess: () => queryClient.invalidateQueries({ queryKey: ['commentList'] }), }); const handleComment = () => { mutate(content); }; return ; }

코드를 요약하면 다음과 같습니다.

useMutation 훅에 댓글 작성 함수를 mutationFn에 등록

성공시에 commentList 라는 쿼리키를 가진 쿼리가 더이상 유효하지 않다고 onSuccess에 등록

댓글 작성 시 mutation을 실행시킴.

mutation이 성공한 뒤 queryClient.invalidateQueries를 실행 시켜 commentList에 해당하는 쿼리를 다시 받아옴

이를 통해 refetch 함수를 강제로 실행시키지 않아 CommentUploadButton 컴포넌트와 ComentList의 결합도를 낮추었습니다.

이러한 개선 과정을 통해 TanStack이 get이아닌 요청에 대해 useMutation을 쓰라고 권장하는 이유가 post이 요청되는 타이밍이 렌더링 시점이 아닌, 특정 이벤트를 받아 body값을 전달한다는 이유이지 않을까 조심스럽게 추론해 봅니다.

혹시 잘못된 부분은 댓글로 알려주시면 감사하겠습니다.🙇🏻‍♂️

rAF를 이용하여 성능과 UX를 잡아보자!!!

Wed, 22 Nov 2023 15:51:48 GMT

약 1년전 쯤 위 영상 처럼 순서를 기억하는 게임 프로젝트를 구현한 적이 있습니다. 혹시 위 영상에서 UX쪽으로 불편한 점이 느껴지시나요? 개발 당시 남은 시간을 알려주는 타이머 부분이 뚝뚝 끊기는 것이 불량품처럼 마음에 들지 않았습니다. 그 당시에 임시방편으로 해결한 방식과 rAF(requestAnimationFrame) 기법을 이용하여 학습했던 과정을 작성해보려고 합니다.

왜 불량품일까?

문제를 개선하기 전에는 원인을 분석해야 합니다. 이를 위해 작성했던 코드를 보며 원인을 분석해 봅시다. 문제인 부분만 직관적으로 이해하기 위해 불필요한 로직은 생략했습니다!

// MemoryGameTimer.tsx (타이머 UI 컴포넌트) import { Progress } from '@chakra-ui/react'; function MemoryGameTimer() { const { time, startTimer } = useTimer(); useEffect(() => { startTimer(); }, [startTimer]); return ; } // useTimer.ts (Timer 로직을 담아 둔 hook) function useTimer() { const INITIAL_TIME = 60000; // 60s const INTERVAL_MILLISECOND = 1000; // 1s const [time, setTime] = useState(INITIAL_TIME); const intervalRef: { current: NodeJS.Timeout | null } = useRef(null); const startTimer = useCallback(() => { if (intervalRef.current !== null) return; intervalRef.current = setInterval( () => setTime(time => time - INTERVAL_MILLISECOND), INTERVAL_MILLISECOND, ); }, []); return { time, startTimer }; }

간단하게 코드 흐름을 설명하면 다음과 같습니다.

MemoryGameTimer 컴포넌트는 타이머의 UI 담당을 하고 있습니다. 이 프로젝트에서는 스타일링을 위해 chakraUI 라이브러리를 사용하고 있고 제공되는 타이머UI 컴포넌트를 사용하였습니다. 남은시간인 time 상태에 따라 Progress Bar의 size가 변화하게 됩니다.

useTimer hook은 Timer 로직을 담고 있습니다. 게임의 제한시간은 60s로 설정하였고, 남은시간을 time 상태에 담아 MemoryGameTimer 컴포넌트에 제공합니다.

time 컴포넌트는 설정한 시간 간격 1s 마다 setInterval에 의해 setTime이 반복적으로 호출되며 time 상태가 새롭게 변경됩니다.

여기서 문제가 무엇인지 확인 하셨나요??

네 맞습니다. 60초의 타이머를 1초마다 갱신을 하다보니 60번의 렌더링이 발생하였습니다. 이는 타이머를 60등분으로 나누어서 이동하기에 뚝뚝 끊어진 고장난 타이머가 되어 버린것입니다....

간격을 줄여보자!

그럼 1초의 간격을 더 촘촘하게 만들면 되지 않나요? 라고 생각을 하실 수 있는데요. 작년의 저도 같은 생각으로 1s를 10ms 간격으로 INTERVAL_MILLISECOND 변수를 변경하여 해결을 했었습니다.

으음... 확실히 이전보다 부드러워 진것 같죠?? 타이머를 60등분을 했던 것과 다르게 6000(60s / 0.01s)등분을 하다 보니 확실히 연속된것 처럼 보이네요!

10ms 마다 상태를 변경하여 렌더링 시키는 것이 성능적으로 안좋지 않을까? 라는 생각을 했었습니다.

하지만 일단 해결은 됐으니 급한 다른 부분을 해결하고 돌아오자 라며 방치를 해두었죠... (그렇게 1년이 흐르고 잊혀질때 쯤에...)

requestAnimationFrame

부트캠프 교육을 받던 중 rAF(requestAnimationFrame) 함수를 알게 되었고 애니메이션을 좀 더 부드럽게 하기 위해서 적용을 할 수 있다고 마스터님께서 말씀하셨습니다. 그 때 1년 전 불량품 타이머를 만들었던 기억 갑자기 떠오르면서 이걸 적용해 보면 해결 할 수 있을거 같다! 생각하였습니다.

적용하는 법은 간단하지만 어떠한 원리로 애니메이션이 부드러워 지는지 알 필요가 있기에 브라우저 렌더링 과정부터 시작하여 좀 더 학습해 봅시다.

렌더링 동작 과정

이 그림을 보며 어떻게 브라우저 화면에 그려지는지 알아봅시다.

HTML 파일을 분석하여 DOM 트리를 구성

CSS 파일을 분석하여 CSSOM 이라는 스타일 트리를 구성

두 트리를 합쳐서 실제로 브라우저에 렌더링할 렌더 트리를 구성하여 화면에 보여줌 3-1. 만약 JS로 DOM을 조작하면 (예를들어 버튼을 클릭하여 리스트 추가) Reflow 단계에서 새롭게 구성 3-2. 만약 CSS를 조작하면 (예를들면 색상을 검정에서 파랑으로 변경) Repaint단계에서 새롭게 구성

우리는 타이머의 스타일이 계속해서 변경되는 것이니 Repaint가 계속해서 일어난다고 생각해도 좋을 것 같습니다.

Frame

우리가 모니터를 살때 60Hz, 144Hz 라는 주사율을 확인할 수가 있습니다. 특히 144Hz는 게이밍 모니터라고도 불리는데 이러한 차이가 무엇일까요?

60Hz란 1초에 60번 렌더링이 될 수 있다고 생각하면 쉽습니다. 예를들어 다음과 같은 타이머의 제한시간이 1초라고 하면

1초전

1초후

모니터가 60Hz 주사율을 가지고 있다면 1초동안 저 타이머 막대기는 60등분되어 60번 줄어들면서 1초후에 없어질 것입니다. 1초 / 60 = 16.66 ms 이므로 16ms 마다 새롭게 렌더링이 될 수 있습니다.

그럼 144HZ 주사율을 가지고 있으면 어떨까? 1초동안 144등분되어 줄어들면서 144번 줄어들고 1초후 사라질것입니다. 1초 / 144 = 6.94 ms 이므로 7ms 마다 새롭게 렌더링이 될 수 있습니다.

그럼 조금 더 잘게 쪼개서 보여준 144HZ가 좀 더 부드럽고 자연스럽게 보이지 않을까요?

이렇게 하나의 새롭게 랜더링 된 하나의 장면을 frame 이라고 합니다.

rAF 동작 이해

그럼 rAF는 어떻게 작동하는 것일까? 먼저 많은 사람들이 60Hz를 사용하므로 주사율이 60Hz라고 가정해봅시다.

rAF를 적용하여 timer의 스타일을 갱신하는 timerAnimation 함수는 주사율에 맞게 브라우저가 적절하게 실행합니다. 그러면 우리는 timerAnimation이 한번 실행될 때 마다 화면에 변경된다고 보장할 수 있습니다. 만약 144Hz 라면? 간격이 7ms 마다 실행되는것 외에는 동일합니다.

setInverval 비교

그럼 이전에 작성한 rAF가 아닌 setInterval로 10ms 마다 실행하면 어떻게 될까요?? 아마 다음과 같이 예상하실 수 있을 겁니다.

이렇게 실행이 되면 무엇이 문제일까요? 우리 화면은 16ms 단위로 화면이 렌더링 되기에 16ms 사이에 함수가 여러번 실행되어도 1번만 적용이 됩니다. 이러면 CPU 입장에서는 의미 없는 일을 하는 격이기에 낭비라고 볼 수 있겠네요. 하지만 더 큰 문제가 있습니다.

과연 setInterval이 우리가 원하는 대로 시간에 맞춰 실행이 될까?

Event Loop

*JS에서 작동하는 Timer는 우리가 생각하는대로 딱 정확하게 실행되지는 않습니다. *

그러한 이유는 JS는 싱글 쓰레드 언어이기 때문인데요. 싱글 쓰레드 언어는 단순하게 한번에 하나의 작업만을 할 수 있다는 것을 의미합니다. 하지만 구현을 하다보면 I/O나 비동기 이벤트(이 경우에는 타이머)를 처리해야 하는 경우가 종종 생기는데 이는 Event Loop를 통해서 JS엔진이 똑똑하게 처리합니다.

이 사진은 유명한 이벤트 루프 동작을 나타내는 사진 중 하나인데요. 이벤트 루프에 대해서는 다음 기회에 자세하게 다뤄보도록 하고 지금은 간단하게 과정만 설명하겠습니다.

JS에서 실행되는 함수는 CallStack에 들어갑니다.

만약 즉시 실행 가능한(동기) 함수 일 경우 CallStack에 바로 빠져 나와 실행됩니다.

타이머나 그 외 비동기적인 작업은 WEB APIs에 넘겨지고 해당 비동기가 끝나면 Callback Queue로 실행 되어야 할 함수가 넘겨집니다.

Event Loop는 CallStack이 비어있을 때 까지 기다린 후 Callback Queue 순서대로 함수를 CallStack으로 옮깁니다.

여기서 위의 10ms Interval을 생각해 봅시다. 만약 10ms가 끝나서 Callback Queue에 timerAnimation 함수가 들어갔는데 CallStack에 아직 작업들이 남아있다면?? EventLoop는 이 작업이 끝날때 까지 기다리게 되고 그럼 우리가 원하는 10ms 마다 실행할 수 없겠죠?

그래서 어떻게 구현하는데?

브라우저에서 정말 고맙게도 frame을 새로 그릴때 실행되어야 할 함수를 등록할 수 있는 window.requestAnimationFrame 이라는 함수를 제공하고 있습니다. 이는 setInteval 처럼 등록하는 것이 아니고 다음 1번의 frame을 그릴때 실행 되는 1회성 함수입니다. 그릴때 마다 실행 되기 위해선 재귀를 사용해서 계속해서 불러야 한다고 MDN 에 나와있네요.

코드

// MemoryGameTimer.tsx (타이머 UI 컴포넌트) import { Progress } from '@chakra-ui/react'; function MemoryGameTimer() { const { time, startTimer } = useTimer(); useEffect(() => { requestAnimationFrame(startTimer); }, [startTimer]); return ; } // useTimer.ts (Timer 로직을 담아 둔 hook) function useTimer() { const INITIAL_TIME = 60000; // 60s const [time, setTime] = useState(INITIAL_TIME); const startTime = useRef(null); const startTimer = useCallback((timeStamp: number) => { if (!startTime.current) { startTime.current = timeStamp; } const elapsedTime = timeStamp - startTime.current; setTime(INITIAL_TIME - elapsedTime); if (elapsedTime < INITIAL_TIME) { requestAnimationFrame(startTimer); } }, []); return { time, startTimer }; }

결과는 ??

아주 부드러운 UX를 제공하고 있습니다 👍 유저는 만족하면서 게임을 즐길 수 있겠군요 ㅎㅎ 유저에게 좀 더 부드럽고 만족스러운 UX를 제공하고 싶으시면 rAF를 이용해 보시는 것도 좋은 방법이라고 생각이 됩니다!

미해결

하지만 아쉬운점이 몇가지 있었습니다.

1. setState 사용

위 코드는 비동기 함수인 setTime을 통해 적절한 시점에 time의 상태를 변경하고 이를 기반으로 타이머 Progress Bar Animation이 작동합니다. 그런데 브라우저가 Frame을 새로 그리기 전 time 이라는 State가 변경이 반영되었다고 확신할 수 있을까요?? 이 부분에 대해선 좀 더 고민해봐야 할것 같습니다.

2. 성능 관점에서의 비교

블로그를 작성하며 사실 10ms간격과 rAF 썼을때의 UX측면에서 결과 비교가 잘 안나기 때문에 조금 아쉬운 마음을 가지고 CPU나 Memory에서 어떠한 차이가 있는지 측정을 해보고 싶었습니다. 하지만 어떠한 방식으로 해야할지 잘 알지 못해서 숙제로 남겨두었습니다...😭

혹시 잘못된 부분이나 아쉬운 점을 해결할 방법을 댓글로 알려주시면 감사하겠습니다.🙇🏻‍♂️

웹 애니메이션 최적화 reflow & repaint How JavaScript works: an overview of the engine, the runtime, and the call stack

Lighthouse CI 적용

Thu, 16 Nov 2023 09:29:26 GMT

새로운 기능을 추가하고 PR 전 lighthouse를 수동으로 체크하는 것이 너무 귀찮은데 자동화 할 수 없을까?

와 같은 생각으로 lighthouse CI를 적용해 보았습니다. 기존에 너무나 자세하게 작성된 카카오 기술 블로그 를 많이 보면서 활용하였습니다.

Lighthouse

Lighthouse 는 구글에서 개발한 웹사이트의 성능 측정 도구입니다. 사용 방법은 간단합니다. 먼저 개발자 도구에서 lighthouse 탭을 들어간 뒤 Analyze page load 버튼을 클릭합니다.

다음 사진은 네이버 메인 페이지의 성능 검사 결과 입니다.

성능은 평가 지표에 따라 점수가 달라질 수 있기에 lighthouse가 무조껀 정답이라고는 할 수 없을 것입니다. 하지만 보편적으로 편리하게 많이 사용하고 있기에 lighthouse의 평가 지표를 기준으로 프로젝트 성능 개선을 시도해보는 것 또한 좋을 것 같습니다.

Lighthouse CI

lighthouse CI github 를 보면 어떠한 방식으로 무엇을 설정할 것 인지 자세하게 설명이 되어있습니다. 저는 먼저 설정 파일을 작성해보겠습니다.

.lighthouserc.js

module.exports = { ci: { collect: { startServerCommand: 'npm run start', startServerReadyPattern: 'ready on', url: ['http://localhost:3000'], numberOfRuns: 3, settings: { preset: 'desktop', }, }, upload: { target: 'filesystem', outputDir: './lhci_reports', reportFilenamePattern: '%%PATHNAME%%-%%DATETIME%%-report.%%EXTENSION%%', }, assert: { assertions: { 'categories:performance': ['warn', { minScore: 0.9 }], 'categories:performance': ['error', { minScore: 0.8 }], 'categories:accessibility': ['error', { minScore: 0.9 }], 'categories:best-practices': ['error', { minScore: 0.9 }], 'categories:seo': ['error', { minScore: 0.9 }], }, }, }, };

먼저 collect의 경우 어떠한 환경에서 실행되는지 설정값 입니다. 여기서 numberOfRuns의 의미는 lighthouse를 몇번 실행할 것인가? 로 저는 3번 실행 하여 점수를 확인하는 것이 좋다고 판단했습니다.

upload의 경우 실행 결과 파일을 어디에 저장할 지 설정하는 부분 입니다.

assert의 경우 warn의 기준 점수, error의 기준 점수에 대해서 설정을 하고 이 값보다 낮은 경우 결과값은 fail을 보여줍니다.

물론 100점이먼 너무 좋겠지만 현실적인 부분을 고려하여 perfomance는 90점 이하는 경고 80점 이하는 에러를 발생 시켰습니다.

lighthouse.yml

그 다음 github에서 trigger을 시키기 위해 root파일에서 .github/workflows 폴더를 생성하고 lighthouse.yml 파일을 생성하였습니다.

name: Run lighthouse CI When Push on: [push] jobs: lhci: name: Lighthouse CI runs-on: ubuntu-latest env: working-directory: ./client steps: - uses: actions/checkout@v2 - name: Use Node.js uses: actions/setup-node@v1 with: node-version: '16' - name: Install packages run: yarn install && yarn global add @lhci/cli@0.8.x working-directory: ${{ env.working-directory }} - name: Build run: yarn build working-directory: ${{ env.working-directory }} - name: Run Lighthouse CI run: lhci autorun env: LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }} working-directory: ${{ env.working-directory }}

그 뒤 origin으로 Push를 하게 성공시 다음과 같은 lhci/url 창에 점수가 뜨게 됩니다.

하지만 이 브랜치가 merge가 되고 나면 해당 점수를 다시 확인할 수 없다는 불편함을 겪었습니다. 그래서 githuh bot이 comment를 달아놓으면 merge 후에도 확인할 수 있어 좋을것 같다고 판단하고 위의 yml에 추가적으로 구현을 하였습니다.

- name: Format lighthouse score id: format_lighthouse_score uses: actions/github-script@v3 with: github-token: ${{secrets.GITHUB_TOKEN}} script: | const fs = require('fs'); const results = JSON.parse(fs.readFileSync("${{ env.working-directory }}/lhci_reports/manifest.json")); let comments = ""; results.forEach((result,index) => { const { summary } = result; const formatResult = (res) => Math.round(res * 100); Object.keys(summary).forEach( (key) => (summary[key] = formatResult(summary[key])) ); const score = (res) => (res >= 90 ? "🟢" : res >= 70 ? "🟠" : "🔴"); const comment = [ `⚡️ Lighthouse report ${index}`, `| Category | Score |`, `| --- | --- |`, `| ${score(summary.performance)} Performance | ${summary.performance} |`, `| ${score(summary.accessibility)} Accessibility | ${summary.accessibility} |`, `| ${score(summary['best-practices'])} Best practices | ${summary['best-practices']} |`, `| ${score(summary.seo)} SEO | ${summary.seo} |`, `| ${score(summary.pwa)} PWA | ${summary.pwa} |`, `\n`, ].join("\n"); comments += comment + "\n"; }); core.setOutput('comments', comments) - name: comment PR uses: unsplash/comment-on-pr@v1.3.0 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: msg: ${{ steps.format_lighthouse_score.outputs.comments}}

카카오 블로그에서는 FCB, LCP등 좀 더 상세한 정보도 활용하였지만 이 프로젝트에서는 불필요하다고 생각이 되어서 핵심적인 Perfomance, Accessibility, Best practices, SEO, PWA 5가지만 테스팅 하였습니다.

여기서 처음 알았던 사실은 secrets.GITHUB_TOKEN 토큰값은 개발자가 직접 작성하는 것이 아닌 기본적으로 github에 설정되어 있다는 것 입니다.

결과

이후 PR을 날려보면 다음과 같이 git-bot이 lighthouse 성능 지표에 대해 코멘트를 달아 주었습니다.

lighthouse CI를 통해서 좀 더 효율적으로 프로젝트를 테스팅 할 수 있었습니다. 이와 같은 테스팅 자동화로 좀 더 유저에게 최적화된 사이트를 제공하는 것이 중요하다고 생각합니다.

React-quill에서 tiptap 으로 - 2부

Sun, 05 Nov 2023 12:20:45 GMT

1부 에서 작성한 글에 이어 2부를 작성해보려고 한다. 2부에서는 어떻게 lowlight로 게시글의 코드블럭에 색상을 넣었는지 많은 삽질과정을 확인해보자.

codeblock

왜 코드블럭에 색상을 넣어야할까?

아래의 두 코드블럭만 비교해봐도 쉽게 알 수 있다. 얼마나 가독성에 있어서 차이가 나는지...

const a = 1; const b = 2; console.log(a+b);
const a = 1; const b = 2; console.log(a+b);

우리 프로젝트는 개발자를 위한 커뮤니티이기에 문법 색상을 넣는것은 필수라고 생각했고 사용할 수 있는 2가지 라이브러리를 찾아보았다.

Prism.js

lowlight

Prism.js

Prism.js 는 syntax highliter 중 가장 유명하고 많이 쓰이는 라이브러리 이다. 웹 사이트에서 볼 수 있듯이 React 공식문서를 포함한 많은 곳에서 사용되고 있다. 많이 사용된다는 것은 업데이트도 자주 된다는 의미일 것이고 정보도 많기에 적용 해보려고 시도했었다.

적용하는 방식은 inline으로 head 파일에 다운받은 css(스타일링 색상),js(파싱을 위한 함수)을 다음과 같이 적용해 볼 수도 있다.

바닐라 스크립트 환경이였으면 충분히 적용해볼만 했지만 npm으로 관리하는 것이 편할것이라 판단 되어 Prismjs 모듈을 설치하여 진행하였다.

NEXTJS 환경에서는 게시글 을 참고하여 CSR 시에 Prism.highlightAll() 함수를 실행하여 해당 컴포넌트의 code 블럭에 색상을 넣고싶었다. 다음과 같이 코드를 작성해보았다.

import React, { useEffect } from 'react'; import { useEditor, EditorContent } from '@tiptap/react'; import ToolBar from '../Toolbar'; //tiptap import StarterKit from '@tiptap/starter-kit'; import Highlight from '@tiptap/extension-highlight'; import Prism from 'prismjs'; import 'prismjs/themes/prism-tomorrow.css'; interface TiptapProps { content: string; } const Tiptap = ({ content }: TiptapProps) => { const editor = useEditor({ extensions: [StarterKit, Highlight], }); useEffect(() => { Prism.highlightAll(); }, []); useEffect(() => { if (content) { editor?.commands.setContent(content); } }, [content]); return ( editor?.commands.focus()} /> ); }; export default Tiptap;

하지만 결과는 적용되지 않았다...!!!(그렇게 쉽게 될리가 없지...)

그럼 원인이 뭘까? 고민을 해보고 몇가지 디버깅을 해보았다.

NEXTJS 환경에서 안되는건가?

Tiptap과 호환이 되지 않는걸까?

내 프로젝트와 의존성 문제가 발생했나?

일단 1번의 경우 이전 참고 사이트가 있는것을 보면 NEXT 환경에서도 된다는 것으로 판단하였다. 그럼 2번 문제가 가장 클것인데... 그래서 tiptap으로 작성된 html 코드를 정적으로 작성해보고 결과를 확인해보았다.

const a = 1; const b= 2; console.log(a+b);

오! 작동이 잘 되는것을 확인할 수 있었다.!!

이 결과로 Prism.highlight() 함수는 해당 컴포넌트 의 codeblok을 확인하고 스타일링을 하는데 Tiptap의Content 내부로는 들어가지 않거나 혹은 게시글은 정적인 코드가 아닌 동적 코드이기에 useEffect가 계속해서 작동이 되지 않아서 그런걸 수도 있겠다라고 생각했다.

후자의 경우 dependency에 content상태를 넣어 타이핑을 칠떄마다 Prism.highlight()를 실행할 수도 있겠지만 그건 원하지 않았다. 그래서 Tiptap에서 추천하는 lowlight 라이브러리를 사용하였다.

lowlight

tiptap에서 lowlight 사용법에 대해서 자세히 설명되어있으므로 그대로 구현했는데 다음과 같은 에러가 발생되었다. (억까의 시작)

이때 쫌 승질이 났다... 하라는대로 했는데 왜 없다는거야!!!

Tiptap은 업데이트가 늦다는 지인의 말이 생각이나 설마 lowligt 버전 업데이트되면서 변경됐나 싶었다. 이럴땐 lowlight 공식문서를 확인해보자.

역시나... tiptap 공식문서에서 사용되는 lowlight 버전은 v2.7.0 이고 현재 최신버전은 v3.1.0 이라 메이저 버전 업데이트로 인해 export 하는 값이 변경되었다. 이에 따라 사용법도 바뀐것이다.!! ~~버전 호환성 문제는 자주 발생하지만 적응이 안된다 하하하~~

그래서 먼저 3.1.0 버전으로 적용을 해보고 문제가 발생하면 공식문서 버전인 2.7.0으로 특정 버전을 설치하여 해결해보려 하였다.

오오~~ 드디어 codeblock에 색상이 들어오기 시작했다!👏 하지만 새로운 문제가 발생했다.

문제상황

const a= 1; 이라는 코드를 복사 붙여넣기를 했는데 이상하게 메타태그와 함께 html 코드까지 붙여넣기가 된다는 문제였다...

이거 만만치 않을거 같다는 예감이 있었다... 붙여넣기에서 문제가 발생한거 같으니 Tiptap에서 관련 정보가 있나 찾아보았다.

참고를 보면 정확하게 나의 상황과 같지는 않지만 addNodeView 와 같은 함수를 확인할 수 있었다.

그럼 addNodeView 을 이용하여 현재 html에서 내부 TEXT 만 받아와서 return 값으로 넘겨주면 되지않을까?

콘솔을 찍어가며 내부 프로퍼티 탐색 후 위 생각처럼 구현해보았는데 잘 되지않았다. 역시 쉬운건 없다... Syntax Highligh 없어도 되지않을까? 잠깐 유혹에 넘어갈뻔 했지만 다시 마음을 다잡고 에러 분석을 해보았다.

디버깅

먼저 뭐가 문제일까 논리적으로 생각해보자.

이 또한 NEXTJS 환경문제?

나의 프로젝트와 의존성 문제?

lowlight의 3.1.0 버전의 문제?

스택오버플로우나 lowlight 깃이슈를 봐도 nextJS 문제는 확인할 수 없었다. 그럼 2,3번일 가능성이 있는데 2번 먼저 디버깅을 해보았다.

의존성 문제가 있는지 확인하기 위해서 나는 항상 새 프로젝트 에서 해당 라이브러리만 설치하여 동작 시켜본다. 예전에는 로컬에서 확인했었지만 이번에는 CodeSandbox라는 좋은 플랫폼을 알게되어 사용해 보았다. 코드 직접 만든 독립적인 환경에서 실행해보니 다음과 같이 잘 작동하는 것을 알 수 있다. 그럼 2번 문제라고 생각이 되어서 어떻게 해결을 해야 하나 고민이 많았다.

하지만 생각보다 어이없게 yarn-lock 파일을 제거한 뒤 yarn install을 통해 재설치하니 의존성 문제가 해결되어 정상적으로 코드 복붙이 잘 되어버렸다.😫 아마도 기존에 깔려있는 모듈과 충돌이 발생해서 이러한 버그가 발생한게 아닐까 싶다.

마무리

끝은 조금 엉성하지만 문제가 발생했을 때 하나하나 디버깅을 해보며 독립적인 환경에서 어떠한 것이 문제인지 해결하는 능력을 키웠다.👍

혹시 잘못된 부분이나 더 나은 해결방법이 있으면 댓글로 알려주시면 감사하겠습니다.🙇🏻‍♂️

React-quill에서 tiptap 으로 - 1부

Sun, 05 Nov 2023 07:48:06 GMT

React-Quill을 버린 이유

게시글 기능 구현을 위해 react-quill 라이브러리를 사용했었다. 하지만 본인 프로젝트의 경우 NEXTJS 환경에서 구현을 하다보니 사용하면서 많은 걸림돌이 발생했었다.

1. SSR의 지원 x

먼저, Quill 에디터의 경우document에 접근하는 코드가 존재하는데 SSR 환경에서 렌더링 시 브라우저가 없지 않은가? 그럼 당연히 window 객체는 존재하지 않게되고 이미지와 같은 에러가 발생하였다.

구글링을 하다가 링크를 보며 dynamic import를 사용하여 동적으로 브라우저에서 CSR에서 시도하여 해결은 하였다.~~(이때 오픈소스를 기여하고 싶었지만 방대한 코드의 양에 압도당해 미뤄두었다.😭)~~

2. 커스터마이징 불편

벨로그와 같은 깔끔한 디자인의 에디터를 제공하고 싶었는데 생각보다 커스터마이징 하기가 힘들었다. 또한, react-quill의 늦은 업데이트 속도는 다른 라이브러리 이전 욕구가 뿜뿜했다.

직접 라이브러리 구현?

사실 처음에는 내가 직접 에디터 라이브러리를 만들어 보자! 로 시작하였다. Velog, Tiptap, 오늘의집 등등 다양한 코드와 기술블로그를 학습하며 적용해보았으나 구문 parsing 하는 법, 디자인, 렌더링 등등 너무 고려할 부분이 많아 시간적으로 부담이 되었다. 다음 기회에 있으면 다시 도전해보려고 한다..😱

Tiptap 도입

다른 라이브러리들 중에 Tiptap을 고른이유는 몇가지 있었다. 먼저 지인들의 추천으로 Tiptap 사이트를 들어갔었는데 너무나 깔끔한 디자인과 직관적인 example 구성방식은 주니어 개발자 나도 쉽게 따라할 수 있을거 같다는 느낌을 받았다. 또한, 다양한 프레임워크(React,Vue,NextJS,Svelt 등)를 지원한다는 점이 매력적이였다. 또한 수많은 extension plugin은 내가 Tiptap을 사용하지 않을 이유가 없었다.

기능 구현

Example 이 너무 잘 나와 있어서 그대로 보면서 구현을 했다. 최종 작성한 Tiptap의 컴포넌트를 먼저 확인하고 세부 내용으로 들어가 보자.

//Tiptap.tsx import React, { useEffect } from 'react'; import { useEditor, EditorContent } from '@tiptap/react'; import ToolBar from '../Toolbar'; //tiptap import StarterKit from '@tiptap/starter-kit'; import Highlight from '@tiptap/extension-highlight'; import Image from '@tiptap/extension-image'; import CodeBlockLowlight from '@tiptap/extension-code-block-lowlight'; import { common, createLowlight } from 'lowlight'; interface TiptapProps { content: string; } const Tiptap = ({ content }: TiptapProps) => { const lowlight = createLowlight(common); const editor = useEditor({ extensions: [ StarterKit, Highlight, Image.configure({ inline: true, allowBase64: true }), CodeBlockLowlight.configure({ lowlight, }), ], }); useEffect(() => { if (content) { editor?.commands.setContent(content); } }, [content]); return ( editor?.commands.focus()} /> ); }; export default Tiptap;

Toolbar

Toolbar의 경우 기본 제공하는 것이 이쁘지가 않아서 google icon 을 사용하여 커스터마이징을 하였다. css는 tailwindcss로 스타일링하였다.

Toolbar code

//Toolbar.tsx import React from 'react'; import { Editor } from '@tiptap/react'; import { Icon } from '../icons'; interface ToolBarProps { editor: Editor | null; } function ToolBar({ editor }: ToolBarProps) { if (!editor) return null; return ( ); } export default ToolBar;

여기서 특히 어려웠던 점은 이미지 업로드 툴바였다. Tiptap의 이미지기능 을 보면 다음과 같은 로직으로 editor에 사진이 설정되는 것을 알 수 있다.

이미지의 URL을 입력한다.

이미지의 URL을 의 html로 변경한다.

이 변경된 html을 editor에 추가된다.

하지만 Velog나 다른 에디터들을 보면 로컬에 있는 사진을 업로드 하거나 드래그 앤 드랍 방식으로 하는 것이 보편적인 것을 알 수 있다. 그럼 내가 직접 구현해야하는 것이 뭘까?

을 이용하여 이미지 추가 툴바 클릭 시 로컬에서 파일 받아오기 기능 구현

사진을 에디터로 드래그 앤 드랍 시 이 이미지의 정보를 저장하기

그럼 차례대로 해결해 보자.

AddImage

로컬에서 파일 받아오기

해당 버튼 아이콘에 를 추가하여 아이콘 클릭 시 다음과 같은 창을 띄워 파일을 선택하려고 한다.

그러기 위해서 아래 사진 같이 코드를 작성하면 나오는 input의 고유 버튼 인 파일 선택 버튼을 클릭해야하는데 file 타입의 스타일링이 조금 까다로워 버튼 이미지 크기를 파일 선택 버튼 크기로 꽉 채워서 해결을 하였다.

icon 적용 전

icon 적용 후

그럼 이제 버튼 클릭 시 파일을 불러올 수 있다. 그럼 어떻게 파일의 정보를 받아올까? 일반적으로 input 태그의 onChange 태그의 event를 통해서 값을 접근할 수 있다. 다음 코드를 보면 이해가 될 것이다.

function AddPhoto() const handleUploadPhoto = async (files: FileList | null) => { if (files === null) return; const file = files[0]; console.log(file); }; return ( ); }

필자는 input에 파일 데이터에 변화가 생기면 데이터를 백엔드에 Post 요청을 하여 저장을 하였고 응답 값으로 해당 URL을 받아오는 로직으로 구현을 하였다.

최종적으로 이미지 추가 버튼 코드이다.

//core import React from 'react'; import { useSession } from 'next-auth/react'; //constants import { ModalType, errorMessage } from '@/constants/constant'; //service import { BASE_URL } from '@/service/base/api'; import { postManager } from '@/service/post'; //third party import { Editor } from '@tiptap/react'; import { useModal } from '@/hooks'; function AddPhoto({ editor }: { editor: Editor }) { const handleUploadPhoto = async (files: FileList | null) => { if (files === null || !editor) return; const file = files[0]; const formData = new FormData(); formData.append('file', file); const imgHash = await postManager.uploadImage(formData, accessToken);// 백엔드에게 이미지 Post요청 후 URL 받기 const IMG_URL = `${BASE_URL}${imgHash}`; editor.commands.setImage({ src: IMG_URL }); }; return ( ); } export default AddPhoto;

Drag And Drop (미해결)

두번째로 드래그 앤 드랍으로 에디터에 바로 사진을 넣고싶었다. 다행히도 Tiptap pro의 File Handler extension를 이용하면 쉽게 해결될 줄 알았지만 생각보다 난관이 있었다.

pro라는 어감이 유로 버전이라 생각 했지만 무료 버전도 어느정도 제공되는것 같아서 다행이었다.

.npmrc

문서를 보며 따라하던 중 .npmrc 라는 새로운 파일을 알게되었다. .npmrc 파일에 나의 토큰 정보를 넣어서 npm 모듈 설치 할때 인증인가를 도와주는 파일이라는 것을 보고 npm 라이브러리가 private으로 제공할 수도 있구나라는 것을 알게되었다. npmrc는 인증인가 뿐 아니라 npm 환경설정, 패키지 scope 등 다양한 기능을 제공하는 것 같았다. 참고

필자의 경우 node 패키지 관리툴로 yarn을 사용하고 있어 다음과 같이 .yarnrc 를 설정하였다.

"@tiptap-pro:registry" "https://registry.tiptap.dev/" "//registry.tiptap.dev/:_authToken" "나의토큰정보"

그뒤 yarn add @tiptap-pro/extension-unique-id 를 실행 하였는데 다음과 같은 에러가 발생하였다.

공식문서의 예시대로 npm으로 설치할 경우에는 잘 되는 것을 보면 2가지 정도로 원인을 생각해 볼 수 있을거 같다.

.yarnrc의 파일 설정을 잘못하여서 authCode를 읽지 못한경우

tiptap-pro의 경우 yarn 지원을 하지않는다?

아무래도 .yarnrc 파일을 처음 사용하다 보니 나의 문제라고 생각은 되지만 많은 구글링과 지피티를 사용해도 문법적인 오류는 발견을 못했다. (혹시 알고 계신분은 댓글로 제발 알려주세요😭😭)

그럼 두번째 경우로 tiptap 라이브러리 내부 문제인데 500에러라고 무조껀 서버 문제라고 단정지을수도 없을 뿐더러 npm은 되고 yarn은 안되는 경우를 겪은적이 없어서 당황스럽다. npm으로 설치를 하면 작동은 되겠지만 두가지의 노드패키지를 사용하기에는 관리 차원에서 부담스럽기도 하기에 이후에 해결하려고 남겨두었다. ~~(나중에 업데이트가 되면 될 수도 있지 않을까 하는 행복회로?)~~

작성하다 보니 글이 길어진 것 같아 lowlight를 활용하여 code block에 색상을 넣은 경험을 2부로 넘기려고 한다!

혹시 잘못된 부분이나 더 나은 해결방법이 있으면 댓글로 알려주시면 감사하겠습니다.🙇🏻‍♂️

GPT 기능 구현 후 빌드 Error 해결 과정기

Mon, 23 Oct 2023 08:45:55 GMT

프로젝트를 진행 중 OPEN AI의 API를 활용하여 GPT 기능을 넣어 보았다. 처음에는 비용적인 부분이 걱정이 되었지만 OPENAI의 가격정책을 보면 input, ouput이 1K token 라는 가정하에 0.0035$ 정도라 현재 유저가 많은 서비스가 아닌 만큼 크게 부담이 되지 않았다. OPEN AI의 API를 사용하여 GPT 기능을 구현하는 방법은 공식문서 이외에도 많은 글들이 존재해 이번에는 CI 환경에서 빌드 중 발생한 에러 해결과정 및 배운점을 적어 보려고 한다.

문제상황

로컬 환경에서는 에러 없이 잘 작동 하였는데 git action으로 build 테스트시에 다음과 같은 에러가 발생했다.

응? OPEN_API_KEY가 없다고? KEY값을 어디서 사용하더라...

에러 해결을 위해 사용되는 코드 부분을 찾아 보았다.

//open AI의 api 사용을 위한 전처리 파일 입니다. import OpenAI from 'openai'; const openai = new OpenAI({ apiKey: process.env.NEXT_PUBLIC_OPEN_API, dangerouslyAllowBrowser: true, }); async function getCodeReview({ code, question, }: { code: string; question: string; }) { const completion = await openai.chat.completions.create({ messages: [{ role: 'user', content: `${code} \n ${question} ` }], model: 'gpt-3.5-turbo', max_tokens: 1024, }); return completion.choices[0].message.content; } export default getCodeReview;

해결시도 1 (env파일 추가)

아! 현재 API 키는 env.development에 저장되어 있고 gitignore에 env.development 파일이 설정되어 있기 때문에 빌드시에는 OPEN_API 값을 받아올 수 없기에 에러가 떴구나😅 그럼 빌드 전에 env 파일을 넣어주면 되지 않을까?

이러한 고민을 하여 yml 파일에 Generate Environment Variables File for Production 이름을 가진 코드를 추가하여 빌드 전 env 파일에 NEXT_PUBLIC_OPEN_API 값을 넣어주었다.

name: 'test-lint-build' on: push: pull_request: jobs: test: name: Test lint, build runs-on: ubuntu-latest env: working-directory: ./client steps: - uses: actions/checkout@v2 - name: Use Node.js uses: actions/setup-node@v2 with: node-version: '18' - name: Cache node modules uses: actions/cache@v2 id: cache with: path: node_modules key: npm-packages-${{ hashFiles('**/package-lock.json') }} - name: Generate Environment Variables File for Production run: echo "NEXT_PUBLIC_OPEN_API=${{ secrets.NEXT_PUBLIC_OPEN_API }}" >> .env - name: Install Dependencies run: npm install working-directory: ${{ env.working-directory }} - run: npm run lint if: ${{ always() }} working-directory: ${{ env.working-directory }} - run: npm run build if: ${{ always() }} working-directory: ${{ env.working-directory }}

해결될것 같았지만 여전히 같은 에러가 발생하였다. 무엇이 문제일까? 고민하다 두가지 의문점이 들었다.

NEXTJS 환경에서 env 환경변수에 NEXT_PUBLIC이 의미하는게 뭘까?

개발 환경에서는 .env.development 를 사용하고 있었는데 .env, .env.development 차이가 뭘까?

1. NEXT_PUBLIC

Non-NEXT_PUBLIC_ environment variables are only available in the Node.js environment, meaning they aren't accessible to the browser (the client runs in a different environment).

In order to make the value of an environment variable accessible in the browser, Next.js can "inline" a value, at build time, into the js bundle that is delivered to the client, replacing all references to process.env.[variable] with a hard-coded value. To tell it to do this, you just have to prefix the variable with NEXT_PUBLIC_. NEXTJS

요약하면, 일반적으로 env 변수는 NodeJS 환경에서만 사용할 수 있는데, 만약 브라우저 환경에서도 사용하고 싶으면 환경변수 앞에 접두사로 NEXT_PUBLIC_을 붙여야 한다.

결론적으로 나는 브라우저 환경에서 GPT 기능을 사용하기 위해 NEXT_PUBLIC_ 을 추가적으로 붙여주었었고 이는 NODEJS 환경에서도 잘 작동하니 문제의 원인이 아니였다.

참고로 process.env.NODE_ENV 는 현재 실행 환경이 development,test,production 인지 구분해주는 내장 환경 변수이다. 이를 활용하여 환경에 따라 의도적으로 다른 작업을 할 수도 있을 것 같다. (예를들면 개발환경, 배포환경에서 서버에 요청하는 URL를 다르게 한다던지???)

2. ENV

매번 프로젝트 할떄마다 env 파일을 사용하지만 여러 env 종류와 의미를 알지못해 학습해 보았다.

ENV 종류

.env: 기본 파일. .env.local: .env를 덮어쓰는 파일. Test를 제외한 모든 환경에서 로딩

.env.development: 개발자 환경에서 로딩 .env.test: 테스트 환경에서 로딩 .env.production: 프로덕션 환경에서 로딩

.env.development.local, .env.test.local, .env.production.local: 각각 env.* 를 덮어쓰는 파일 참고

ENV 실행 우선순위

npm start: .env.development.local > .env.development > .env.local > .env npm run build: .env.production.local > .env.production > .env.local, .env npm test: .env.test.local > .env.test > .env (note .env.local is missing)

정확히 알고 사용한 것은 아니였지만 개발환경에서는 .env.development 파일로, git action CI 빌드 환경에서는 .env 파일로 사용하여 이 또한 문제가 아니였다. (만약 빌드 환경에서 .env.development로 만들었다면 npm run build 실행 시 파일을 읽지 못했을 것이고 이를 원인이라고 생각했을 수도 있겠다.)

해결시도 2 (OPEN AI 코드 탐색)

env 설정은 잘해주었는데 왜 OPEN_API 값을 못찾을까?? 도대체 어떤 방식으로 코드를 짰길래...

이러한 생각으로 OPEN_AI의 에러 처리 방식을 라이브러리를 뜯어보며 찾아보았다. open-ai/src/index.ts

//open-ai/src/index.ts ... constructor({ apiKey = Core.readEnv('OPENAI_API_KEY'), organization = Core.readEnv('OPENAI_ORG_ID') ?? null, ...opts }: ClientOptions = {}) { if (apiKey === undefined) { throw new Errors.OpenAIError( "The OPENAI_API_KEY environment variable is missing or empty; either provide it, or instantiate the OpenAI client with an apiKey option, like new OpenAI({ apiKey: 'My API Key' }).", ); } ...

open-ai/src/core.ts

//open-ai/src/core.ts ... export const readEnv = (env: string): string | undefined => { if (typeof process !== 'undefined') { return process.env?.[env] ?? undefined; } if (typeof Deno !== 'undefined') { return Deno.env?.get?.(env); } return undefined; }; ...

이 코드를 보면서 OEPN AI의 코드 구현 방식을 생각해 보았다.

생성자 인자로 apiKey가 들어오면 그 값을 사용

없는 경우는 readEnv 함수를 통해 env파일에 OPENAI_API_KEY 변수가 있나 확인하고 있으면 그대로 사용, 없으면 undefined 반환

apiKey가 undefined일 경우 Error 던짐

나는 현재 아래와과 같이 NEXT_PUBLIC_OPEN_API(open ai에서 탐색하는 OEPNAI_API_KEY가 아님을 주의) 값을 설정해 놨었고 2번으로 분기 되지 않겠다는 것을 생각했다. 그럼 결론적으로 빌드 환경에서 OPENAI의 인자로 apiKey값이 들어가기는 할텐데 3번이(에러) 발생한다는 것은 apiKey가 undefined 라는 의미이고, 결국 아직도 build 환경에서는 env를 못찾는구나.

//open AI의 api 사용을 위한 전처리 파일 입니다. ... const openai = new OpenAI({ apiKey: process.env.NEXT_PUBLIC_OPEN_API, dangerouslyAllowBrowser: true, }); ...

해결 방식 (working-directory)

너무나도 허무하게 문제는 env 파일 생성 경로를 잘못 지정해 주었기 때문이다.~~(그러니 계속해서 env 파일을 못찾았지...😭)~~ 이 프로젝트 폴더 구조는 root-client 구조로 되어있어 프로젝트를 실행하기 위해서는 clinet 폴더로 변경하여 run을 실행시켜야했다. 하지만 Generate Environment Variables File for Production 에서는 working-directory를 변경하지 않아 env 파일은 root 폴더에 npm build는 client에서 실행되어 문제가 발생했던 것이다.

그래서 다음과 같이 working-directory를 추가한 yml 파일로 CI build 테스팅을 성공시킬 수 있었다.

name: 'test-lint-build' on: push: pull_request: jobs: test: name: Test lint, build runs-on: ubuntu-latest env: working-directory: ./client steps: - uses: actions/checkout@v2 - name: Use Node.js uses: actions/setup-node@v2 with: node-version: '18' - name: Cache node modules uses: actions/cache@v2 id: cache with: path: node_modules key: npm-packages-${{ hashFiles('**/package-lock.json') }} - name: Generate Environment Variables File for Production run: echo "NEXT_PUBLIC_OPEN_API=${{ secrets.NEXT_PUBLIC_OPEN_API }}" >> .env working-directory: ${{ env.working-directory }} - name: Install Dependencies run: npm install working-directory: ${{ env.working-directory }} - run: npm run lint if: ${{ always() }} working-directory: ${{ env.working-directory }} - run: npm run build if: ${{ always() }} working-directory: ${{ env.working-directory }}

이번 에러를 통해 개발자의 성장은 에러를 해결하는 과정에서 가장 크다고 느꼈다. 만약 working-directory 설정을 안해줬다는것을 바로 알아차렸다면 해결은 빠르게 했을지 몰라도 NEXT_PUBLIC의 의미, ENV 종류와 특징, OPEN_AI가 API를 받아오는 과정을 학습할 수 없었을 것이다. 삽질하는 과정을 너무 부정적으로만 생각하지 말고 성장의 영양제라고 생각하자!😊

NextJS의 꽃 pre-render

Tue, 23 May 2023 12:52:28 GMT

나도 예전에는 NextJS는 Server-side Rendering방식이야~ 라고만 생각하며 개발을 한적이 있다. 지금 생각해보면 NextJS가 유명하다고 무작정 따라하기만 했던거 같다... 😭 이번 기회에 공식문서를 정리를 해보며 NextJS의 강점인 pre-render에 대해 알아보자.

NextJS 프레임 워크를 쓰는 가장 큰 이유 중 하나는 pre-render 방식이라고 생각을 한다. 이 pre-render 방식은 무엇이고 기존 React의 render와 무엇이 다른지 알아보자.

사전지식

Next JS에서는 페이지 단위로 어떠한 렌더링 방식으로 작동할 것인지 선택할 수 있다. 이는 SPA(Single Page Application) 방식을 사용하는 React 방식과 차별점이라고 볼 수 있다.

Render

렌더링 이란? HTML,CSS, 자바스크립트 등 개발자가 작성한 문서가 브라우저에서 출력되는 과정을 말한다.

기존 CSR의 render 방식을 생각해 보자

사이트에 접속시 브라우저는 서버에게 HTML 및 JS 파일을 요청하게 된다. HTML 파일에는 위 사진과 id가 root인 텅텅 빈 HTML 파일이 오게되고 이후 용량이 무거운 JS파일이 다운 후 DOM을 이 태그 안에 그리면서 rendering이 된다.

단점

이렇게 rendering이 client에서 진행이 되면 속도가 느릴 뿐 아니라 웹 크롤러가 이 사이트가 어떤 사이트인지 알 수가 없어 SEO(검색 엔진 최적화)에 불리해 구글과 같은 검색엔진에 검색을 해도 노출이 잘 되지 않는다.

Pre-render

브라우저에 컴포넌트들이 rendering 되기 전 먼저 rendering 과정을 진행 하여 빠르게 화면에 보여주는 방식

NextJS에서는 Static Site Generation (SSG) 방식과 Server-side Rendering (SSR) 방식으로 pre-render를 진행한다.

아래 사진과 같이 DB에 게시글 정보가 있다고 시나리오를 설정 하자.

Static Site Generation (SSG)

하나의 페이지가 SSG 를 사용한다면, 이 페이지의 HTML은 build time에 생성된다.

개발 -> 빌드 -> 배포 과정을 통해 유저가 웹사이트를 확인할 수 있다.

빌드를 하게 되면 코드를 수정하고 싶을 경우 다시 빌드 후 배포 과정을 밟아야 한다.

물론 블로그, 자기소개서나 소개페이지 같은 경우 자주 변경되는 페이지가 아니다 보니 이 SSG 방식을 쓰면 매우 유리하다. 그냥 완성되어 있는 HTML 정적 페이지 자체를 렌더링 시키는것은 브라우저 입장에서 별거 아니기 떄문에 매우매우 빠르기 때문이다.😎

매번 HTML 파일에다가 하드코딩을 해서 빌드 -> 배포 할 수도 있다. 하지만, 서버에 게시글 정보를 저장하고 그 데이터를 fetching해서도 정적 페이지를 만들고 싶을때가 있을것이다. 그럴 경우에 getStaticProps 를 이용해보자.

getStaticProps

위 코드의 경우 우리가 일반적으로 생각하는 정적페이지라고 생각해보자. 이때에는 서버로 부터 fetching 할 필요도 없으니 그냥 정적파일로 빌드 되어서 배포되면 된다.

하지만 게시글 정보가 서버로 부터 받아야 할 경우가 있을 것이다. 이때에는 getStaticProps를 사용해보자.

이렇게 getStaticProps를 사용하면 build Time때 이 데이터를 fetching하여 게시글을 받아오고 이 데이터를 기반으로 정적 파일을 만든다.

그렇기에 계속해서 정적파일을 유지할 수 있다. 하지만 Data base에 있는 게시글 정보가 수정 되면 어떻게 될까? 클라이언트 측에서는 빌드타임때 사용한 예전 게시글 정보를 기반으로 보여주기 때문에 새로 업데이트를 하기 위해서는 다시 빌드 후 배포를 진행해야 한다.

자주 변경되는 데이터의 경우 정적파일이 아무리 빠르게 렌더링이 되어서 좋다 하더라도 데이터가 바뀔때마다 빌드 -> 배포 과정을 진행해야 하니 얼마나 비효율 적인가...

그래서 데이터가 잘 바뀌지 않는 포트폴리오나 블로그에 사용하자.

한가지 더 추가하자면 NextJS Default는 SSG 이다. 만약 페이지에 데이터를 동적으로 작용하는 것이 없다면 그 페이지 자체는 정적 파일로 만들어도 충분하지 않을까? Next JS는 내부적으로 판단 하여 해당 페이지를 정적 파일로 만들어 버린다.

Server-side Rendering (SSR)

SSG 렌더링을 사용하기에는 데이터가 자주 변하는데 그럼 어떻게 할까?

이 때 SSR 방식을 사용하곤 한다. SSG의 경우 서버로 부터 데이터 요청을 빌드타임에 한다.

하지만, SSR의 경우 클라이언트가 프론트엔드 서버에게 Page request를 할때 프론트엔드 서버가 백엔드 서버에게 데이터를 요청한다.

대략적인 흐름을 보자.

클라이언트는 프론트 서버에게 브라우저에 보여줄 해당 페이지 자원(HTML,CSS,JS 등등)을 요청한다.

Front 서버는 Back 서버에게 필요한 정보(게시글)를 요청하여 받는다.

Front 서버는 이 데이터를 기반으로 HTML,CSS 등 필요한 자원을 만든다.

Client에게 페이지에 필요한 자원를 제공한다.

SSG와 다른점이 무엇일까? 먼저 데이터를 서버로 부터 언제 받는가이다.

SSR은 새로고침을 할때마다 매번 Client는 프론트서버에게 해당 페이지 자원을 요청하고 게시글 정보를 새롭게 받아오기 때문에 서버의 데이터가 변경되었다 하더라도 새로 빌드 -> 배포 할 필요가 없다.

또한, CSR의 경우 클라이언트 렌더링 할때 데이터를 받아오는 반면 SSR의 경우 page request시 데이터를 요청하기에 빠르게 받아올 수 있다. 하지만, 데이터를 프론트서버로 부터 한번만 받아오기 떄문에 새로고침을 하지 않는 이상 데이터가 re-fetching이 되지 않는 것이 단점이다.

그렇기 때문에 자주 변경되는 정보들은 SSR 방식을 사용하면 현재 페이지에 보여지고 있는 정보와 실제 정보와 다를 수 있다.

getServerSideProps

사용법은 SSG와 거의 다르지 않다. page 파일 내에서 getStaticProps -> getServerSideProps 로만 바꾸면 된다.

그럼 NextJS는 아하, 이 데이터는 빌드타임이 아니라 server-side에서 요청해야겠다 로 판단한다.

지금까지 SSG와 SSR에서 데이터를 언제 어떻게 fetching 하여 HTML 파일을 만들어 rendering을 하는지 알아 보았다. Next는 Page 단위로 rendering 방식을 결정하고 있음을 기억하자.

Client-Side Rendering (CSR)

그럼 REACT의 CSR 방식에서는 데이터를 언제 어떻게 불러왔는가 생각을 해보며 글을 정리 해보자.

클라이언트가 프론트 서버로 부터 빈 HTML 파일과 JS 파일을 받는다.

클라이언트에서 렌더링이 시작되고 Mypage가 렌더링이 되면 post 상태는 null로 초기화가 된다.

useEffect 훅을 통해 data를 fetching 한다.

setPost를 통해 data가 백엔드 서버로 부터 받은 정보를 기반으로 post상태를 변화시킨다.

클라이언트는 게시글을 볼 수 있다.

차이점이 보이는가? SSG와 SSR의 경우 1번일 때 이미 서버로 부터 데이터를 다 받아온 상태이다. REACT의 CSR의 경우 3번에서 데이터를 받아온다.

REACT의 경우에는 1번에서 용량이 큰 JS 파일을 한번만 다운 받으면 그 뒤에는 페이지를 옮기 더라도 1번이 생략되어 빠르게 작동한다.

SSR의 경우 페이지 이동시 1번(서버로 부터 페이지 자원을 받음)부터 시작하기에 속도측면에서 역전당한다.

하지만 NextJS에서도 useEffect를 통해 데이터를 Client-sdie에서 받을 수 있다.

결론

NextJS는 페이지 단위로 렌더링을 결정한다.

SSG는 빌드타임에 데이터를 fetching 할 수 있다.

SSR은 백엔드 서버에게 페이지 자원 요청시 데이터를 fetching한다.

useEffect를 통해 NextJS에서도 Client-side에서 데이터를 fetching 할 수 있다.

개발자는 페이지마다 어떤 렌더링 방식을 사용할 것 인지는 페이지 특성을 고려하자.

출처 : NextJS Docs Next.js - SSR이라고만 알고있었다.

Git merge에 관하여

Mon, 08 May 2023 16:57:08 GMT

"우리 팀은 merge 전략을 rebase로 하자" 라는 말과 함께 프로젝트를 진행하였다. 하지만 rebase merge를 하려는 중 얼마 못가 conflict를 마주쳤고 정확한 원인을 알지 못했다. merge에 대해 정확하게 알지 못하고 있다고 깨닫고이번 기회에 merge에 대해 깊게 공부를 해보려 한다. 이 글을 통해 다른 개발자들도 merge 개념의 이해에 도움이 되면 좋겠다.

Merge 란?

브랜치 간에 변경 사항을 병합하는 작업이다.

Merge에 방식에는 크게 1-1. Fast forward merge 1-2. Recursive merge 2. Squash and merge 3. Rebase and merge 가 있다.

깃허브에서 merge하는 방식을 보면 3가지 방식이 있는것 또한 확인할 수 있고 각각의 Merge의 특징을 살펴보며 차이점을 살펴보자.

1-1. Fast forward merge

Before merge

After merge

가장 기본적인 Merge 방식이다. main 브랜치에서 dev 브랜치로 분기 후 dev 브랜치에서 작업을 하다 이 작업 결과를 main 브랜치에 그대로 옮기는 방식이다.

dev의 B와 C 커밋 그 자체가 main에 복사 된다고 생각하면 된다. (커밋의 해쉬값 까지 동일하다)

조건

이 Fast forward merge를 할 수 있는 경우는 dev가 main에서 분기 후 main에서는 어떠한 작업도 하지 않을 경우이다.

1-2. Recursive merge

Before merge

After merge

가장 많이 사용하는 일반적인 Merge 이다. 개발을 진행해보며 Fast forward merge 처럼 main에서 어떠한 작업도 이루어 지지 않는 경우는 거의 없었다. Merge 하기 전 팀원들의 작업물 들이 main에 먼저 Commit된 경우가 대다수이기 때문이다.

이처럼 A Commit 에서 분기된 dev 브랜치가 B,C 작업을, A Commit 이후 main 브랜치에서 X,Y작업을 진행한 상황에서 dev 브랜치의 작업을 main에 Merge를 해야할 때가 있다.

이 때에는 Git 입장에서 Y Commit과 C Commit 중 어떠한 것이 먼저 일어난 것인지 알 수 없고 따라서 HEAD를 어디에 이동 시켜야 할지 모른다.

따라서 새로운 Z Commit 을 생성하고 dev 브랜치 작업물을 main에 merge 한다. 그럼 main에는 B,C,Z 3개의 Commit 내역이 추가된다.

이것이 Recursive merge(Commit 후 merge를 하기에 commit merge라고 많이 부르는것 같다)이다.

충돌

main에서 작업했던 것(X,Y)와 dev에 작업했던 것(B,C)이 충돌이 일어나곤 한다. 같은 파일을 수정하는 경우가 있기 때문이다. 이때에는 어떤 코드를 사용할 지는 사람이 결정해서 코드를 수정 후 Z와 같이 Commit을 진행한다. 이것은 Resolve conflict 라고 한다.

2. Squash merge

Before merge

After merge

개발을 하면서 한번도 사용한 적이 없는 Merge 방식이다. 공부를 하면서 이 merge 방식도 상당히 매력이 있다고 느꼈다. main branch commit 내역에 dev의 commit이 합쳐져 하나의 Commit으로 깔끔하게 보이기 때문이다.

위와 같이 dev에서 main 으로 merge를 하기 전 B,C가 합쳐진 새로운 D Commit을 만들고 main으로 merge 된다. 이때 main 브랜치는 B,C 커밋은 존재하지 않고 D만 존재하게 되어 깔끔한 Commit 이력을 유지할 수 있다. ~~하지만 다른 브랜치에서 열심히 작성한 커밋 이력이 모두 없어지기에 잔디가 심어지지 않는다 ㅠㅠ~~

3. Rebase merge

Before merge

After merge

마지막으로 rebase merge이다. 이 게시글을 쓰게된 merge의 장본인이라고 할 수 있다. 이 merge 방식은 1-1의 Fast-forward merge 방식으로 볼 수 있는데 다른 점은 main에 어떠한 작업이 존재해도 merge를 할 수 있다는 것이다.

또한, Fast-forward merge 일 경우에 dev 브랜치의 Commit들이 그대로(해시값 유지) main 브랜치로 복사가 됐지만, rebase의 경우 커밋내용은 동일하지만 새로운 커밋들(해시값이 다름)이 main브랜치에 복사된다고 할 수 있다.

merge commit을 하지 않기 때문에 main 브랜치 하나로 작업한 것 처럼 보여 매우 깔끔한 commit내용을 유지할 수 있다.

충돌

그럼 1-1의 Fast-forward와 다르게 Rebase merge의 경우 dev 분기 후 main에 작업이 존재할 수 있고 이것은 dev와 충돌이 발생할 수 있다. 이때 dev와 main의 충돌 난 부분을 하나하나 해결하고 rebase를 다시 진행하면 해결할 수 있다.

하지만 나의 경우 위의 방식처럼 dev로 main을 먼저 Recursive merge을 진행한 뒤 다시 main에 Rebase merge를 진행하려고 하여 D의 Commit은 main의 부모를 가지고 이 브랜치 때문에 꼬여서 Rebase merge를 진행하지 못하였다. 이 경우에는 다시 main 브랜치로 Commit Merge를 진행할 수 밖에 없다.

결론적으로 Rebase는 main 브랜치와 dev 브랜치가 충돌이 나지 않을 경우 merge를 진행할 수 있고 만약 충돌이 난다면 dev 브랜치에서 충돌난 부분을 하나하나 풀어 Rebase를 진행해야한다. main의 브랜치를 dev로 merge 후 다시 main으로 merge를 진행하려고 하면 Rebase를 쓸 수 없고 commit Merge를 진행하자.

참고 : https://mangchhe.github.io/git/2021/09/04/GitMerge/ https://kotlinworld.com/277 https://goddaehee.tistory.com/253 https://wonyong-jang.github.io/git/2021/02/05/Github-Rebase.html https://backlog.com/git-tutorial/kr/stepup/stepup2_8.html

HTTP란?

Tue, 13 Sep 2022 14:59:37 GMT

HTTP(Hyper Text Transfer Protocol)?

클라이언트와 서버가 통신할 때 하이퍼텍스트(HTML,CSS,JS 등등)을 교환하는 규약을 말한다.

이 규약이 없으면 클라이언트와 서버가 데이터를 교환할 수가 없다.

HTTP의 특징

클라이언트가 어떠한 요청을 하면 그에 대한 응답을 서버는 해야 한다. 이때 서버는 클라이언트의 상태를 보존하지 않고(무상태 프로토콜) 연결을 계속 유지 하지도 않는다(비 연결성).

이러한 특징을 가지는 이유를 아래에서 알아보자.

무상태 프로토콜 - Stateless

간단하게 말하면 서버는 클라이언트들의 상태를 저장하지 않는 것이다. 즉, 매번 요청을 할때마다 필요한 상태들을 클라이언트에서 보내주어야 서버는 이해하게 된다. 아래의 상담원(서버)과의 예시를 보자.

A(클라이언트) : 안녕하세요? A 입니다. 상담원A(서버) : 반갑습니다. A님. 무엇을 도와 드릴까요? A(클라이언트) : B에게 5000원을 송금하고 싶습니다. 상담원B(서버) : 성함이 어떻게 되세요?

위의 예시와 같이 상담원B의 경우 A <-> 상담원A 의 정보 교환을 알지 못한다. 그래서 상담원 B는 A의 성함을 알지 못한다. 이런 상황을 피하려면 한번에

'제 이름은 A이고 B에게 5000원을 송금하고 싶습니다'

와 같이 필요한 상태를 한번에 보내야 할 것이다.

이러한 장점은 무엇일까? 먼저 서버에 부담을 덜어준다. 모든 클라이언트의 정보를 담고 있는것은 서버에 부담이 되기 때문에 필요할 경우에 클라이언트에서 보내주는것이 서버 입장에선 편하다. 그래서 보다 많은 클라이언트와 통신 할 수 있다.

하지만 단점의 경우 위에서 말했듯이 매번 클라이언트가 서버에게 상태를 보내야 하는 것이다.

그래서 매번 필요한 자주쓰이는 상태는 서버에 저장하고 상대적으로 덜 쓰이는 것은 클라이언트가 보내주는 것이 좋아 보인다.

비 연결성 - Connectionless

HTTP 1.0 기준 HTTP는 연결을 유지하지 않는 모델이다.

왜 연결을 유지 하지 않을까? 위의 상담원 예시를 확장 해보자. 만약 연결성을 유지 한다고 가정하자.

A(클라이언트) : 안녕하세요? A 입니다. B에게 5000원을 송금하고 싶습니다. 상담원A(서버) : 반갑습니다. A님. B에게 5000원이 송금 되었습니다. A(클라이언트) : 감사합니다. (전화는 계속 유지된다.) (1시간 뒤 ) A(클라이언트) : B에게 10000원을 송금하고 싶습니다.

위의 예시와 같이 A는 다음 요청이 1시간 뒤에 발생하는데 연결성을 유지 될 경우에 상담원 A는 아무 일도 하지 못하고 A의 응답만 기다려야하는 비효율성이 나타난다. 따라서 연결성을 유지 하지 않고 필요할 경우에 다시 연결을 하는 방식이다. (이는 컴퓨터 구조시간에 배운 멀티 프로그래밍과 비슷하다고 생각한다. 진행중인 프로세스가 블록 상태가 된 경우 CPU는 다른 프로세스를 수행한다.)

HTTP vs HTTPS

그런데 우리 주소창을 보면 http가 아닌 https로 되어 있는 것을 볼 수 있다. 이건 왜그럴까??

예전보다 보안이 훨씬 중요해진 요즘 보안은 필수이다. 하지만 http의 프로토콜의 경우 서버에서 부터 클라이언트로 전송되는 정보가 암호화되지 않는것이다. 만약 이것이 도난 당하면 큰일이기 때문에 SSL(보안 소켓 계층)을 사용하여 서버와 클라이언트의 정보 교환을 암호화 한다.

또한 구글에서도 검색 순위 결과에 약간의 가산점을 준다고 하는데 이는 구글에서도 HTTPS의 보안성을 강조함을 알 수 있다. 그리고 유저 또한 보안상 안전한 사이트를 방문할 수 밖에 없다.

참고 https://developer.mozilla.org/ko/docs/Web/HTTP/Overview https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-http-http%EB%9E%80-%ED%8A%B9%EC%A7%95-%EB%AC%B4%EC%83%81%ED%83%9C-%EB%B9%84%EC%97%B0%EA%B2%B0%EC%84%B1/ https://blog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/

클라이언트 사이드 렌더링과 서버 사이드 렌더링에 관하여

Wed, 31 Aug 2022 09:33:24 GMT

우리는 SEO(검색 엔진 최적화)가 중요하니 SSR(서버 사이드 렌더링) 방식으로 개발 진행 합시다!!

개발 전 회의를 하다가 위와 같은 말이 나왔었다. 매번 회의할때 모르는 기술이 나오면 당황하고 자신감을 잃는다. 하지만 계속해서 질문을 하고 하나하나 알아가다 보면 생각보다 별거 아니였네? 라는 느낌을 받는다. 사람은 모르는 것을 마주치면 당황하는 것은 당연하다고 생각한다. 모르는 것을 아는 것으로 바꿀때 자신이 성장함을 잊지 말자.

CSR(클라이언트 사이드 렌더링)

SSR을 알아보기 전에 CSR을 먼저 알아보자.

CSR이란 쉽게 말해서 클라이언트에서 모든 것을 처리하는 방식이다. 대표적으로 React가 있다.

SPA

화면간 이동시 깜박임이 없는 SPA(Single Page Application)이 대세가 되면서 CSR이 급 부상했다. 예전 웹페이지의 경우 화면 이동시 서버에서 새로 html 파일을 받아 화면에 보여주어야 해서 깜박임이 존재했다. 하지만 SPA의 경우 데이터 교체만 일어나 UX가 좋은 장점이 있다.

CSR의 과정

위 흐름을 보면 먼저 서버로 부터 html 파일을 요청 한다. 이 html 파일의 경우 클라이언트에서 유저가 볼 컨텐츠 들이 아닌 모듈화 된 JS파일 링크만 들어있다. 그래서 현재 페이지는 빈화면이고 서버로부터 JS파일을 다운 받는다. 이 모듈화 된 JS파일은 클라이언트에서 사용할 모든 필요한 정보들이 들어있어 다운을 받는데 시간이 오래 걸린다. 다운이 완료되면 마침내 유저가 화면을 볼 수 있게 된다.

React 를 사용하여 실습

그림만 보는 것 보다 직접 눈으로 보는 것이 기억에 오래 남고 이해하기 쉽기 때문에 React를 이용하여 CSR의 진행 과정을 확인해 보자.

localhost.html

npx create-react-app 을 통해 만들어진 프로젝트의 처음 화면이다. Network를 보면 localhost의 html 파일을 볼수있다. 화면에는 리액트 마크와 여러 content가 있다. 하지만 body안에는 id가 root인 텅텅 빈 div 태그를 볼 수 있다. 이 파일이 위에서 말한 html 요청한 파일이다.

또한 script 부분을 보면 bundle.js 파일을 불러 오는 것을 알 수 있다.

bundle.js

이 부분은 bundle.js 파일 부분이다. 가독성이 떨어지는 엄청 복잡한 코드로 되어있다. 이는 우리가 필요한 CSS,JS, 이미지 등등 리소스들을 하나의 js 파일에 번들화 되어있기 때문이다. 번들화는 주로 Webpack을 이용한다.

Network

이번에는 파일이 어느 시점에 다운이 되는지 확인해보자

처음 시작부분에 0~~23ms 까지 한번, 27ms~~97ms 까지 한번 총 2구간이 진행됨을 알 수 있다. 처음에는 html부분을 다운받고 그 뒤 js 파일을 다운받는 것이다.

CSR의 단점

1. 텅텅 빈 화면

과정에서 알 수 있듯이 하나의 용량이 큰 JS파일을 다운 완료 전에는 유저는 빈 화면만 보게 된다. JS 파일이 크면 클수록 로딩시간은 더 길어지게 되고 유저는 지루함을 느낄 수 밖에 없다. 이를 해결하는 방법으로 코드 스플릿팅을 통해 하나의 JS가 아닌 여러개의 번들로 나누는 방법이 있다.

2. SEO(검색 엔진 최적화)의 문제

구글과 네이버와 같은 검색엔진은 검색을 할 때 크롤링을 통해 사용자에게 사이트를 제공한다. 이 크롤링 방식에 있어서 검색엔진은 html 파일을 탐색하게 되는데 CSR의 경우 텅텅 빈 html을 보여주므로 검색에 비효율 적일 수 밖에 없다.

SSR(서버 사이드 렌더링)

위와 같은 CSR의 단점을 해결하기 위해 SSR 렌더링을 사용한다. SSR의 경우 html과 css의 부분은 서버에서 먼저 받아와 CSR 단점 1번을 해결해준다. 그뒤 JS 파일을 받아오고 유저는 이 이후에 동적으로 웹을 사용할 수 있게된다. 또한 html에 컨텐츠들이 들어있기 때문에 CSR 단점 2번인 SEO의 문제도 해결할 수 있다.

SSR의 과정

먼저 서버에서 렌더된 HTML 파일을 브라우저에 제공한다. 브라우저는 즉각적으로 유저에게 컨텐츠를 보여준다. 그 뒤 JS 파일이 다시 다운받게 되고 유저는 JS에 관련된 기능들을 사용할 수 있게된다.

Next를 이용한 실습

SSR을 사용하기 위하여 Next.js를 이용하여 어떤식으로 파일을 받아오는지 확인해 보자.

localhost.html

npx create-next-app 을 통해 만들어진 첫 화면이다. 이전 React와 달리 localhost html 파일 내부 body에 content들이 들어가 있다. 이것이 CSR과 SSR의 가장 큰 차이점이다. 이로써 유저는 조금 더 빠르게 첫 화면을 볼 수 있고 검색엔진이 크롤링 하기에 유리하다.

Network

네트워크 창을 보면 0~~100ms 까지 하나의 파일 120~~270ms 정도에 여러개의 파일이 다운되는 것을 볼 수있다. 이는 처음에 html이 다운되는 시간, 이후에 js 파일이 다운 되는 것을 알 수 있다.

SSR의 단점

물론 SSR도 단점이 존재한다. 단점이 없으면 CSR을 쓰지 않지 않겠는가?

1. 화면 깜박임

CSR의 경우 SPA이기 때문에 페이지 이동시 부드럽게 넘어감을 알 수 있다. 하지만 SSR의 경우는 화면이 깜박 거리는 것을 볼 수 있는데 이는 UX 측면에서 좋지 않다.

2. html과 js의 공백

네트워크 창에서 보면 html 다운되는 시간과 js가 다운되는 시간이 차이가 남을 알 수 있다. 이는 유저가 html 다운이 완료되어 첫 화면을 볼 수 있을 시점에 JS가 다운이 되어있지 않으면 기능이 정상 작동하지 않을 수 있다.

CSR+SSR

하지만 Next에서는 Link 태그를 이용해 첫화면은 SSR 그 뒤에 화면 전환은 CSR처럼 사용할 수 있다. 이로 인해 선택적으로 유리한 렌더링 방식을 이용할 수 있다.

참고

https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8 https://www.youtube.com/watch?v=iZ9csAfU5Os https://ctdlog.tistory.com/46

자신만의 Hook을 만들어 보자

Thu, 18 Aug 2022 13:00:05 GMT

문제 상황

지인의 부탁으로 쇼핑몰 제품 정보 관리 페이지를 제작중 문제가 발생하였다.

위와 같이 하나의 제품에는 사진, 제품이름, 영어이름, 중국어이름, 운송장번호 등등 많은 Data값이 존재한다. 이 데이터를 어떤식으로 관리할까 고민하다가 처음에는 아래와 비슷한 방식으로 하나의 상태에 모든 데이터를 넣었었다.

잘못된 방식

const [product, setProduct] = useState([ {ko:'사다리 모던 진열대',en : 'Ladder modern display', ... ,Hscode:'9403209000',id :'acxz123czxdas'} ,{ko:'대왕 거위 모찌 쿠션',en :'Giant goose mochi cushion',...,Hscode:'9403209000',id :'sa5d135zxcsda'} ,...]);

처음에는 상위 컴포넌트에서 하나의 상태에 Data를 관리하여 하위 컴포넌트에게 props 전달하는 방식으로 사용하였다. 하지만 data의 양이 점점 늘어날 수록 데이터 변경 시 딜레이가 발생하기 시작했다.

위와 같은 상품 200개가 product 상태 하나에 전부 들어가 있다고 하자. 그럼 200개중 하나의 객체 프로퍼티값을 setProduct를 통해 수정을 하게되면 나머지 199개의 불필요한 중복이 발생하게 된다. 즉, 값이 변경되는 것은 하나의 상품인데 199개의 상품도 동시에 재렌더링이 발생하게 되는 것이다. 왜냐하면 리액트에서는 재렌더링 조건중 하나가 상태값이 변할 경우이기 때문이다. 그러다 보니 유저가 한글자씩 키보드에서 입력할떄마다 0.5~1 초 정도의 딜레이가 생기고 불만이 생긴 것이다.

이것을 해결하기 위해 Custom Hook을 구현하여 데이터 단위를 쪼개어 주었다.

여기서 Hook이란 무엇인지 알고 넘어가 보자.

Hook

Hook은 React 버전 16.8부터 React 요소로 새로 추가되었습니다. Hook을 이용하여 기존 Class 바탕의 코드를 작성할 필요 없이 상태 값과 여러 React의 기능을 사용할 수 있습니다.

React는 클래스형 컴포넌트와 함수형 컴포넌트로 구현할 수 있다. 클래스형 컴포넌트는 이해하기도 어렵고 클래스 컴포넌트 사이에서 상태로직을 재사용 하기가 어렵다. 함수형태 컴포넌트에서는 비교적 쉽고 간단하기 때문에 선호하지만 이전에는state와 Life Cycle을 사용하기 위해선 어쩔수 없이 클래스형 컴포넌트를 사용할 수 밖에 없었다.

하지만 이 문제점을 해결하기 위해서 Hook 이 나온 것이다. 위에서 말한 state를 사용하기 위해서 useState라는 훅을 Life Cycle를 사용하기 위해서 useEffect라는 훅이 생긴 것이다.

즉, 함수형 컴포넌트에서 클래스형 컴포넌트의 기능을 사용하기 위한 도구라고 보면 될 것 같다.

Custom Hook

그럼 나만의 Hook은 뭘까.

개발을 하다보면 상태 로직이 중복되는 경우가 발생한다.

필자의 경우 위와 같은 데이터를 하나의 컴포넌트로 보면 데이터의 상태와 input box의 onChange로직은 상품 갯수만큼 중복된다고 볼 수 있다.

그래서 아까 같이 하나의 상태에 모든 제품들을 넣는 방식이 아닌 State를 상품마다 독자적으로 만들어 주어야한다.

function useProduct(obj){ const [product,setProduct] = useState(obj); const onChange = (e) => setProduct(e); //... // 상태 로직 관련 함수들 return {product, setProduct, onChange} } export default useProduct; // useProduct.js

import useProduct from '../hooks/useProduct'; //ex) obj = {ko:'사다리 모던 진열대',en : 'Ladder modern display', ... ,Hscode:'9403209000' //,id :'acxz123czxdas'} function DataRow(obj){ const {product, setProduct,onChage} = useProduct(obj); return } // DataRow.js

결론

서버에서 데이터 배열을 받아오고 각각의 데이터 obj를 DataRow 배열에 넣어주면 Row당 상태값이 하나 생기게 된다. 이렇게 Custom Hook을 사용하면 만약 데이터 하나의 값을 변경한다고 할 때 이전 처럼 200개의 데이터가 들어있는 상태를 바꾸는 것이 아닌 하나의 Row에 대한 상태값만 수정되기 때문에 1개의 Row만 렌더링 되어 딜레이를 줄일 수 있었다. 물론 Custom Hook을 사용하지 않고 DataRow.js 파일에 모든 상태를 직접 만들어도 동작은 하겠지만 중복을 줄이기 위해 Custom Hook을 사용하는 것이 좋겠다.

출처

https://ko.reactjs.org/docs/hooks-intro.html

CORS를 알아보자

Thu, 11 Aug 2022 07:29:57 GMT

웹 개발자라면 한번쯤은 봤을만한 CORS 정책을 정리해 보려고 한다.

우리는 개발을 하다보면 수많은 에러를 겪는다. 그럴때 마다 해결에만 초점을 두는 것은 안좋은 습관이라 생각이 들고 그 에러가 뜬 근본적인 이유에 대해 생각해볼 필요가 있는거 같다.

주변 동료나 면접에서 어떠한 에러 관련 질문이 들어왔을때 직접 근본적인 이유에 대해 고민해보았던 부분과 단순히 해결만 했던 부분에 있어서 답변 수준은 확실하게 다르다고 느꼈다.

그럼 지금부터 근본적인 이유를 알아보자!

CORS(Cross-origin resource sharing)

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.

위의 정의에서 출처 라는 부분이 무슨말일까?

출처(Origin)

웹 콘텐츠의 출처(origin)는 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의됩니다. 두 객체의 스킴, 호스트, 포트가 모두 일치하는 경우 같은 출처를 가졌다고 말합니다.

위의 정의에서도 모르는 용어가 팍팍 나온다... 스킴, 호스트, 포트 를 알아보자. 구글(https://www.google.com/)의 URL를 기준으로 위의 예시에 대입을 해보자.

스킴(프로토콜) : https 호스트(도메인) : www.google.co.kr 포트 : 443(생략)

포트는 스킴이 http일경우 80, https 일 경우 443 이라고 한다.

그래서 https://www.google.com:443/ 으로 접속을 해도 https://www.google.com/ 와 같다.

그럼 이제 우리는 출처가 같다는 말을 이해할 수 있다. 구글과 같은 출처를 가진것은 https://www.google.com/~ 와 같다고 할 수있다.

다른 출처의 예제

SOP(동일 출처 정책)

그럼 왜 동일한 출처를 가진 경우에는 안전하고 다른 출처를 가진 경우 자원을 접근할 때 문제가 생겨 CORS 가 발생할까?

예를 들어보자 정상적인 클라이언트 출처 : https://kakao.com 정상적인 서버 출처 : https://kakao.com 해커 클라이언트 출처 : https://kakaoHacked.com

유저가 해커의 클라이언트(kakaoHacked)에 실수로 들어갔다고 하자 (~~필자의 어렸을때 기억으로 넥슨과 UI가 똑같이 만든 해커 사이트에 접속하여 로그인을 한 경우가 있는데 지금 생각해보면 개인정보가 유출 된 것이다.~~)

정상적인 클라이언트와 UI가 같아 아무 의심 없이 로그인을 한다.

정상적인 서버에서 로그인 요청을 받았다. 하지만 이 요청의 출처는 해커(kakaoHacked) 이므로 리소스를 제공해 주지 않는다. (만약 다른 출처에도 리소스를 제공해준다면 유저의 개인정보는 해커의 손에 들어갈 것이다.)

해결책

하지만 다른 출처를 가진 경우에도 리소스를 공유해야 하는 경우가 있지 않은가? 그럴 경우에 서버에서 Access-Control-Allow-Headers 에서 예외적으로 허용해 줄 출처를 설정한다. 설정해 주지 않은 상태에서 출처가 다른 어플리케이션 끼리 공유 할때 CORS 정책을 브라우저에서 알려주는 것이다. 또 다른 방식으로는 프록시 서버를 설정하여 클라이언트 <-> 서버 가 아닌 클라이언트 <-> 프록시 서버 <-> 서버 와 같이 중간에 프록시 서버를 두어 중개 역할을 하는 것이다.

참고

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS https://developer.mozilla.org/ko/docs/Glossary/Origin https://johngrib.github.io/wiki/why-http-80-https-443/

공공 데이터 API를 통해 환율을 받아오자

Wed, 27 Jul 2022 15:01:49 GMT

개인 프로젝트 진행 중 환율 정보를 받아와야 하는 케이스가 생겼다. 공공 데이터의 경우 단순히 URL로 데이터를 요청해서 받아오는 경우 보다 복잡해서 정리해 보려고 한다! 참고로 https://unipass.customs.go.kr/csp/index.do 사이트를 들어가면 환율 정보를 알 수있다.

https://unipass.customs.go.kr/csp/framework/filedownload/kcs4gDownload.do?attchFileId=MYC-20200710-00037918211TiAQI 를 클릭하면 관세청에서 제공하는 연계 가이드 문서를 볼 수 있어 이를 참고 하였다.

사전 작업

이 API 를 사용하기 위해 우선적으로 UNI-PASS의 회원으로 가입되어 있어야 하며, 각각의 용도에 맞는 서비스를 신청한 후 승인을 받아야 사용할 수 있다. 우리는 관세환율이 필요하므로 이를 신청하자! 이 부분은 연계가이드에 친절하게 설명이 되어있기 때문에 생략하겠다.

API 요청

연계 가이드 문서를 보면 관세 환율 정보는 ID값이 API012를 가지고 있다. 우리가 요청해야 하는 URL 주소는 다음과 같다.

URL : https://unipass.customs.go.kr:38010/ext/rest/trifFxrtInfoQry/retrieveTrifFxrtInfo?crkyCn=[인증키]&qryYymmDd=[날짜]&imexTp=2

인증키 부분은 사전작업 을 통해 받을 수 있고 날짜의 경우 원하는 날을 입력하면 된다 ex) 20150101 imexTp가 1 일경우 수출, 2일 경우 수입을 받아온다. 우리의 경우 수입을 예시로 진행할 것이다.

~~환율정보는 매주 일요일 마다 갱신이 되는것 같다.~~

Client 환경에서 우리가 원하는 데이터를 요청해보자. 필자는 React 환경에서 테스트를 해보았다.

Client Code

const getData = async () => { try { const data = await fetch( 'https://unipass.customs.go.kr:38010/ext/rest/trifFxrtInfoQry/retrieveTrifFxrtInfo?crkyCn=[인증키]&qryYymmDd=20220725&imexTp=2', ); console.log(data); } catch (e) { console.log(e); } };

적절한 인증키와 20220725 날짜에 해당하는 데이터 요청시 우리를 항상 괴롭히는 CORS 에러가 발생했다. 그래.. 이렇게 쉽게 원하는 걸 얻을리가 없지...

그럼 CORS 에 대해 간단하게 알아보고 해결해 보자.

교차 출처 리소스 공유 (CORS)

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.

정의는 역시 어렵다. 간단하게 정리해보면 현재 Client에서 사용중인 도메인(현재는 localhost)과 서버의 도메인(UNI-PASS 서버)이 같아야지 서로 리소스(환율 정보)들을 공유할수 있다.(보안상의 이유라고 한다.)

하지만 요즘 다른 도메인 끼리 리소스를 공유해야 하는 경우도 많다. 이럴 경우 필요에 따라 '이 Client 도메인은 우리(서버)와 도메인이 달라도 리소스를 공유하겠습니다.' 라고 서버에 설정 해야한다.

우리가 UNI-PASS 쪽 서버에 접근해 우리의 도메인을 추가 할 수는 없으므로 우리가 서버를 하나 만들어서 UNI-PASS로 부터 데이터를 받아오고 우리쪽 서버에서 우리의 도메인이 리소스를 받을 수 있게 설정하고 데이터를 제공하는 방식으로 해결했다.

대략적인 flow

Server

자신의 서버가 있고 그곳에서 작업하면 좋겠지만 이번 프로젝트의 경우 그러지 못했다. 이것을 위해 서버를 띄운다 해도 너무 과한 느낌이 강하게 들어 나의 용도에 적합한 방법을 찾다 AWS Lambda 라는 서비스를 이용해보았다.

AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스입니다.

프론트 엔드 개발자가 간단하게 서버리스로 코드를 실행하고 싶을때 적합한 방식이라고 판단했다.

그럼 AWS Lambda 함수의 코드 구현을 보면 다음과 같다.

파이썬보다 Node.js가 편해서 Node.js로 구현하였다.

Code

Server

const https = require("https"); let url = `https://unipass.customs.go.kr:38010/ext/rest/trifFxrtInfoQry/retrieveTrifFxrtInfo?crkyCn=[인증키]&qryYymmDd=${getToday()}&imexTp=2`; exports.handler = async (event) => { const resultObj = await new Promise((res, reject) => { https.get(url, (response) => { var result = ""; response.on("data", function (chunk) { result += chunk; }); response.on("end", function () { const body = { headers: { "Access-Control-Allow-Headers" : "Content-Type", "Access-Control-Allow-Origin": "*", "Access-Control-Allow-Methods": "OPTIONS,POST,GET" }, statusCode: 200, body: result, }; res(body); }); }); }); return resultObj; }; function getToday(){ var date = new Date(); var year = date.getFullYear(); var month = ("0" + (1 + date.getMonth())).slice(-2); var day = ("0" + date.getDate()).slice(-2); return year + month + day; }

그럼 관공서에서 제공해주는 형식인 XML로 다음과 같이 출력된다.

음.. 우리는 JSON이 XML 보다 다루기 편하므로 xml-js의 라이브러리를 이용해 변환을 진행하였다.

사실 이 부분에서 lambda 계층에 xml-js 라이브러리를 저장 후 JSON 파일을 전송하는 방법도 있지만 Client에서 JSON으로 변환하는 방식으로 진행하였다.

Client

import { useEffect, useState } from 'react'; import axios from 'axios'; var convert = require('xml-js'); const getData = async setData => { const response = await axios.get( 'AWS API 주소', ); const jsonResponse = convert.xml2json(response.data); const USD = await getUSD(JSON.parse(jsonResponse)); setData(USD); }; const getUSD = data => { let USD = 0; data.elements[0].elements.forEach(e => { if (e.elements?.length > 2) { if (e.elements[3].elements[0].text === 'USD') { USD = e.elements[2].elements[0].text; } } }); return USD; }; function App() { const [data, setData] = useState(); useEffect(() => { getData(setData); }, []); return {data}; } export default App;

위와 같이 진행하면 아래처럼 USD 수입 환율을 받아올 수 있다.

참고

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/welcome.html https://www.npmjs.com/package/xml-js