나에게 기여란 PR의 merge뿐 아니라, 팀의 관점에서 그들의 cost를 줄여주는 모든 것들이다.

오픈소스에서 feature나 fix의 PR을 날리는 것은 멋진 경험이었다.

다만, 다른 기여자들이 쉽게 기여를 할 수 있는 환경과 분위기를 조성하고, 더 많은 사람들이 기여의 즐거움을 알도록 하는 것 또한 지속가능성의 기여이다.

그렇기에 예전엔 크게 매력을 느끼지 못했던 Docs를 작성하거나, test를 고치거나 ESLint의 에러를 고치는 등. 프로젝트를 안정화하고 개발 환경 설정의 난이도를 낮추는 것 또한 굉장히 가치있는 일이라고 생각한다.

Yorkie에서의 첫 달은 이것에 집중하기로 했다.

yorkie-js-sdk

#1016 ESLint Error 및 CI Test fail

issue#1016 issue#1023

PR#1023 PR#1027

1. 개요

1. 해당 project는 최신 pnpm version을 요구하는 환경과 deprecated된 ESLint 버전을 동시에 사용하는 환경이다. 또한, ESLint의존성이 root와 packages에 따로 존재하여, pnpm의 symlink로 참조되는 하위 패키지의 eslint plugin(@typescript-eslint)들을 적절히 load하지 못해 CI레벨의 참조 실패 warning이 예전부터 발생하였다.

해당 PR을 생성하기 전, 존재하던 CI warning(eslint 의존성 플러그인 참조 실패)

1. CWD에 따라 서로 다른 ESLint rule(eslint-typescript 또는 로드 실패시 적용되는 fallback rule인 core rule)이 적용되던 현상이 있었다. 이 문제를 해결하여 기여자들에게 동일한 개발 환경을 제공하고자 한다.
2. .npmrc의 engine-strict를 사용하여 npm와 nodejs의 버전을 강제하지만, package.json에 pnpm에 버전이 누락되어 있어 pnpm의 버전을 강제하지 않고 있었다. 이러한 문제들을 수정하며 기여자들의 환경을 최대한 동기화 하고자 하였다.

2. Issue 생성 및 토의

직접 issue를 생성하고 바로 해결하는 것도 좋지만, 다른 기여자들이 참고할 수 있는 PR을 생성하고 이를 함께 토론하고 해결해 나아가는 과정은 너무 좋은 기억으로 남아있다. 이러한 과정은 다른 기여자들에게 기여의 첫 발을 내딛게 해주며, 꾸준한 기여로 이어질 수 있는 기회를 제공한다.

확인한 Error Flow

CWD에 따라 Array Contstructor 관련 에러가 발생하였다. 해당 공식문서를 찾아보니, @typescript-eslint에서는 이에 대한 에러를 반환하지 않지만, core rule에서는 에러를 반환하는 차이점을 알게 되었다. 이를 기반으로 @typescript-eslint 플러그인이 로드되지 않아 fallback rule인 core rule을 사용하는 것 아닌가 하는 추론으로 부터 문제를 디깅했고, 관련된 에러나 히스토리 문서들을 추적하기 시작했다.

결론은 아래와 같았다.

1. root에 eslint가 설치되어있음.
2. package/sdk에 플러그인들이 설치되어있음.
3. pnpm i 이후, 하위 workspace에 eslint는 root에, plugin들은 하위 workspace에 존재. root에 존재하는 eslint가 plugin을 로드하기 위해 resolver가 돌아가는 과정에서 root의 node_modules를 참조하지만, 이는 하위 workspace에만 존재하고 cwd가 workspace더라도 eslint는 root에 존재(아마 예전 resolver라 symlink관련 파싱 로직이 추가되지 않은 채 deprecated 된 것으로 추론)
4. 로드 에러
5. (추론)@typescript-eslint가 정상적으로 override되지 않고 기본 ESLint rule만 사용(recommended의 core rule은 적용되는 것을 확인했기 때문에 최상단 또는 fallback rule로 recommended가 적용되었다고 생각합니다. 또는 IDE rule일 가능성도 존재)
6. 환경별로 다를 ESLint rule이 적용됨.

이를 수정하는 PR을 날렸고, CI레벨에서 존재하는 ESLint warning 문제와 .npmrc를 사용함에도 engines prop에서 pnpm을 강제하지 않는 오류들을 함께 수정하였다.

결과

• 모든 환경에서 동일한 ESLint Rule을 보장한다.
• 모든 환경에서 공식문서에 기재된 pnpm 버전을 보장한다. 조건에 맞지 않을 경우 의존성 패키지 설치를 막고, 경고 메시지를 반환한다.
• CWD에 따라 발생하던 차이가 있던 ESLint plugin로드 방식을 해결한다.
• 기존에 검증하지 않던 .tsx 파일들의 ESLInt 에러를 해결한다.

#1020 Upstream package 변경에 따른 deprecated flag 변경

issue#1019 PR#1020

개요:

통합 테스트 진행 시 1332개의 test가 실패하는 것을 확인하였다.

문제점을 파악해보니, Upstream(yorkie) 패키지의 flag가 변경되었음을 확인하였다.

이를 해결해결하고, 다른 패키지들에도 동일한 문제점이 있다는 것을 발견하여 전체적으로 업데이트를 진행했다.

yorkie

#1389 AttachDocument의 예외처리에서 Schema version을 반환하지 않음

issue#1389

개요:

yorkie-js-sdk는 yorkie의 Spec을 그대로 추상화한다.

js-sdk의 test spec에 따르면 AttachDocument의 예외처리에서 Schema의 version을 반환해야 하며, Upstream package의 추상화 코드를 보더라도 이에 대한 추상화가 일부 이루어져 있는 것을 알 수 있다.

따라서, 추상화 누락이라고 판단하여 issue를 생성했다.

PR#1024이 이를 closed하였으나, 회귀 테스트에서 버전을 검증하지 아니하고, equal에서 include 메서드로 검증의 강도를 약하게 만든 변경사항이었다. 즉, 문제의 본질은 해결되지 않았다고 생각해, 관련 이슈를 논의하였다.

이에 대한 답변을 받을 수 있었다.

물론, Issue를 다시 생성하고, 이에 대한 추상화를 진행하는 것도 하나의 방법이 되겠지만 현재 단계에서 굳이 추상화 할 필요가 없는 기능이라는 것에 동의하였다. 추후에 이에 대한 업데이트가 이루어지면 js-sdk에서 version에 대한 테스트를 추가하고자 한다.

yorkie-team.github.io

#222 공식문서 CLI 업데이트

issue#222 PR#223

개요:

변경되어 사라진 CLI flag를 여전히 문서로 제공하고 있었다. 이를 수정한 PR

dashboard

#229 Upstream package 변경에 따른 deprecated flag 변경

issue#229 PR#233

개요:

Issue 생성 후, 다른 기여자를 위해 남겨둔 Issue.

sigmaith님이 PR을 제출하여 Issue를 close 해주셨다.

codepair

#496 docker-compose top-level version 삭제 및 Docker image 최신화

issue#495 PR#496

개요:

• docker image 버전 최신화
• Upstream CLI 변경
• docker-compose의 deprecated된 top-level version 수정

다음 달부터는 CodePair의 Feature와 전체적인 회귀 테스트 보강에 신경써볼까 한다.

Strong eventual consistency

• 동일한 update operation set을 가진 노드(ex: client)들은 update Operation의 순서에 상관 없이 최종적으로 같은 상태로 수렴.
• updated operation 발생시 replica에게 state 전파

따라서, 아래의 명제들로 확장할 수 있다.

1. 교환법칙과 결합 법칙이 성립(Operation 순서에 상관이 없기 때문)
2. Duplicated operation 허용한다면 멱등성(Idempotent) 성립X. (무효화한다면 멱등성 성립)

+a 교환법칙, 결합법칙이 성립하는 이유

• CRDT는 기본적으로 라티스의 join(semi-lattice) 구조를 따른다.
• Counter 기반 설계의 경우, 각 replica의 카운터를 더하는 덧셈 연산을 join으로 사용하기 때문이다.

이는 interface일 뿐, 결국

1. Data type 설계
2. Operation merge 전략 에서 교환법칙, 결합법칙, 멱등성의 조건을 만족하도록 추상화 하는 것이 본질로 보인다.

P: 이벤트의 수신 순서에 따라 교환 법칙이 깨지는 경우

하지만 수신받은 Operation의 "순서"가 교환법칙에 위배되는 경우가 있다. 이벤트의 인과관계나 context가 존재하는 경우가 그것이다. 즉, 단순 commutativity만으론 동시 삽입이 어느 순서로 반영돼야 할지 결정할 수 없다.

이는 Operation Event 안에, Vector Clock을 추가하여 해결할 수 있다.

예를 들어, 노드가 수신한 update Operation stack이 [<1,0,0,2>, <1,0,0,0>, <1,0,0,1>]와 같은 경우, 수신 순서와 무관하게 [<1,0,0,0>, <1,0,0,1>, <1,0,0,2>] 순서로 정렬할 수 있음

https://wikidocs.net/156284 https://github.com/jamiebuilds/babel-handbook/blob/master/translations/ko/plugin-handbook.md#toc-asts https://medium.com/basecs/leveling-up-ones-parsing-game-with-asts-d7a6fc2400ff http://astexplorer.net/

PR Issue

1. Issue

vitest의 format 유틸이 %s를 처리하는 방식이 NodeJS Spec이랑 다름. (커스텀 toString 메서드 있을 때, node inspect말고 커스텀 toString 사용해야함.)

%s: String will be used to convert all values except BigInt, Object and -0. BigInt values will be represented with an n and Objects that have no user defined toString function are inspected using util.inspect() with options { depth: 0, colors: false, compact: 3 }.

2. Context 파악

switch (x) {
  case '%s': {
    const value = args[i++]
    if (typeof value === 'bigint') {
      return `${value.toString()}n`
    }
    if (typeof value === 'number' && value === 0 && 1 / value < 0) {
      return '-0'
    }
    if (typeof value === 'object' && value !== null) {
      // 🎯 inspect만 사용. toString 검증 로직 추가해야함.
      return inspect(value, { depth: 0, colors: false })
    }
    return String(value)

3. 회귀 테스트

기존 테스트에 추가해주기

import util from 'node:util'
import { format } from '@vitest/utils'
import { describe, expect, test } from 'vitest'
describe('format', () => {
  const obj = {} as any
  obj.obj = obj
  test.each([
    // ...cases
    [
      '%s',
      new (class {
        constructor(public value: string) {}
        toString() {
          return this.value
        }
      })('string value'),
    ],
    // ...cases
  ])('format(%s)', (formatString, ...args) => {
    expect(format(formatString, ...args), `failed ${formatString}`).toBe(util.format(formatString, ...args))
  })

4. 해결

새로 정의된 toString 메서드가 있는지 확인하고 분기처리하면 끝난다.

switch (x) {
  case '%s': {
    const value = args[i++]
    if (typeof value === 'bigint') {
      return `${value.toString()}n`
    }
    if (typeof value === 'number' && value === 0 && 1 / value < 0) {
      return '-0'
    }
    if (typeof value === 'object' && value !== null) {
      // 🎯 함수면서 && toString이 오버라이딩 되었니? > 그렇다면 toString 호출
      if (typeof value.toString === 'function' && value.toString !== Object.prototype.toString) {
        return value.toString()
      }
      return inspect(value, { depth: 0, colors: false })
    }
    return String(value)

merged

별 다른 피드백 없이 merged

PR Issue

1. Issue

현재 Playwright에서 여러개의 웹서버를 띄울 때, 각 서버 로그의 Prefix가 [WebServer]로 고정되어있다. 각 서버별 로그 파악이 용이하도록 defineConfig 함수에 커스텀 prefix 기능요청이 들어왔다.

2. Context 파악

export class WebServerPlugin implements TestRunnerPlugin {
  // ...codes
  private async _startProcess(): Promise<void> {
    // ...codes
    launchedProcess.stderr!.on('data', data => {
      if (debugWebServer.enabled || (this._options.stderr === 'pipe' || !this._options.stderr))
        this._reporter!.onStdErr?.(prefixOutputLines(data.toString())); // ⛳️
    });
    launchedProcess.stdout!.on('data', data => {
      if (debugWebServer.enabled || this._options.stdout === 'pipe')
        this._reporter!.onStdOut?.(prefixOutputLines(data.toString())); // ⛳️
    });
  }

function prefixOutputLines(output: string): string {
  const lastIsNewLine = output[output.length - 1] === '\n';
  let lines = output.split('\n');
  if (lastIsNewLine)
    lines.pop();
  lines = lines.map(line => colors.dim('[WebServer] ') + line); // ⛳️ 1. 호출하면 WebServer Prefix가 하드코딩 되어있음.
  if (lastIsNewLine)
    lines.push('');
  return lines.join('\n');
}

WebServerPlugin 객체의 this._option에 optional로 name 프로퍼티를 추가해준 뒤, defaultValue를 기존 WebServer로 설정한채 상위에서 name을 매개변수로 주입해주면 쉽게 구현이 가능하다.

3. 회귀 테스트

기존 테스트코드 컨벤션에 맞게 테스트를 우선 추가해준다.

test.describe('name option', () => {
  test('should use custom prefix', async ({ runInlineTest }, { workerIndex }) => {
    const port = workerIndex * 2 + 10500;
    const name1 = 'CustomName1';
    const name2 = 'CustomName2';
    const defaultPrefix = 'WebServer';
    const result = await runInlineTest({
      'test.spec.ts': `
      import { test, expect } from '@playwright/test';
      test('pass', async ({}) => {});
    `,
      'playwright.config.ts': `
      module.exports = {
        webServer: [
          {
            command: 'node ${JSON.stringify(SIMPLE_SERVER_PATH)} ${port}',
            port: ${port},
            name: '${name1}',
          },
          {
            command: 'node ${JSON.stringify(SIMPLE_SERVER_PATH)} ${port + 1}',
            port: ${port + 1},
            name: '${name2}',
          }
        ],
      };
    `,
    }, undefined);
    expect(result.exitCode).toBe(0);
    expect(result.output).toContain(`[${name1}]`);
    expect(result.output).toContain(`[${name2}]`);
    expect(result.output).not.toContain(`[${defaultPrefix}]`);
  });

  test('should use default prefix when name option is not set', async ({ runInlineTest }, { workerIndex }) => {
    const port = workerIndex * 2 + 10500;
    const defaultPrefix = 'WebServer';
    const result = await runInlineTest({
      'test.spec.ts': `
      import { test, expect } from '@playwright/test';
      test('pass', async ({}) => {});
    `,
      'playwright.config.ts': `
      module.exports = {
        webServer: {
          command: 'node ${JSON.stringify(SIMPLE_SERVER_PATH)} ${port}',
          port: ${port},
        },
      };
    `,
    }, undefined);
    expect(result.exitCode).toBe(0);
    expect(result.output).toContain(`[${defaultPrefix}]`);
  });
});

4. 해결

export type WebServerPluginOptions = {
  // ...props
  name?: string;
};

필드 추가하고

// ⛳️ 1. DefaultValue는 기존 Prefix(WebServer) 사용
function prefixOutputLines(output: string, prefixName: string = 'WebServer'): string {
  const lastIsNewLine = output[output.length - 1] === '\n';
  let lines = output.split('\n');
  if (lastIsNewLine)
    lines.pop();
  lines = lines.map(line => colors.dim(`[${prefixName}] `) + line); // ⛳️
  if (lastIsNewLine)
    lines.push('');
  return lines.join('\n');
}

동적 할당하고

launchedProcess.stderr!.on('data', data => {
  if (debugWebServer.enabled || (this._options.stderr === 'pipe' || !this._options.stderr))
    this._reporter!.onStdErr?.(prefixOutputLines(data.toString(), this._options.name));
});
launchedProcess.stdout!.on('data', data => {
  if (debugWebServer.enabled || this._options.stdout === 'pipe')
    this._reporter!.onStdOut?.(prefixOutputLines(data.toString(), this._options.name));
});

주입

이후 문서 작성 및 빌드로 타입 생성해주고 완료

5. Merged

동일한 Feature

해당 피쳐가 merged되고 약 2달 뒤, 핑이 날아왔다.

컨텍스트를 살펴보니 1년 전에 이미 동일한 Feature 요구가 있었고, 그 당시엔 p3로 남았던 건이었다.

꾸준히 관심을 가지고 피쳐 업데이트를 살펴보셨나보다. 가끔 issue 생성자 분들이 이모지를 남겨주시는데, 감사인사를 남겨주셔서 필자가 더 감사할 따름이다.

PR Issue

1. Issue

expect.extend의 커스텀 매처에 제네릭 타입을 주입 할 경우, 부모 객체의 커스텀매처 타입이 추론되지 않는 버그.

2. Context 파악

  expect.extend({
    toBeLike<T>(received: unknown, expected: T) {
      const { isNot, utils } = this
      return {
        pass: received == expected,
        message: () => isNot
        // ⛳️ 부모 객체의 utils의 타입이 유실됨.
          ? `Expected ${utils.stringify(received)} to not be like ${utils.stringify(expected)}`
          : `Expected ${utils.stringify(received)} to be like ${utils.stringify(expected)}`,
        actual: received,
        expected
      }
    },
  })

기존 타입은 아래와 같다.

export interface MatcherState {
  customTesters: Array<Tester>
  assertionCalls: number
  currentTestName?: string
  dontThrow?: () => void
  error?: Error
  equals: (
    a: unknown,
    b: unknown,
    customTesters?: Array<Tester>,
    strictCheck?: boolean
  ) => boolean
  expand?: boolean
  expectedAssertionsNumber?: number | null
  expectedAssertionsNumberErrorGen?: (() => Error) | null
  isExpectingAssertions?: boolean
  isExpectingAssertionsError?: Error | null
  isNot: boolean
  // environment: VitestEnvironment
  promise: string
  // snapshotState: SnapshotState
  suppressedErrors: Array<Error>
  testPath?: string
  utils: ReturnType<typeof getMatcherUtils> & {
    diff: typeof diff
    stringify: typeof stringify
    iterableEquality: Tester
    subsetEquality: Tester
  }
  soft?: boolean
  poll?: boolean
}

export interface SyncExpectationResult {
  pass: boolean
  message: () => string
  actual?: any
  expected?: any
}

export type AsyncExpectationResult = Promise<SyncExpectationResult>

export type ExpectationResult = SyncExpectationResult | AsyncExpectationResult

// ⛳️ 3. this에 MatcherState를 주입한다 << 문제점
export interface RawMatcherFn<T extends MatcherState = MatcherState> {
  (this: T, received: any, ...expected: Array<any>): ExpectationResult
}

export type MatchersObject<T extends MatcherState = MatcherState> = Record<
  string,
  RawMatcherFn<T> // ⛳️ 2.RawMatcherFn<T>를 상속받는다.
>

export interface ExpectStatic
  extends Chai.ExpectStatic,
  AsymmetricMatchersContaining {
  <T>(actual: T, message?: string): Assertion<T>
  extend: (expects: MatchersObject) => void // ⛳️ 1. extend의 MatchersObject는
  anything: () => any
  any: (constructor: unknown) => any
  getState: () => MatcherState
  setState: (state: Partial<MatcherState>) => void
  not: AsymmetricMatchersContaining
}

요약: 메서드가 아닌 함수로 인식된다. this에 대한 타입 정보가 명확히 주어지지 않아 제네릭타입을 강제로 주입하더라도, 무시되기(적절한 추론이 이뤄지지 않기) 때문이다.

위 방식에서는 객체 리터럴로 작성된 함수가 단순 함수로 인식된다. 따라서, 문맥적 this 타입 정보가 주입되지 않는다. 함수 시그니처에 선언된 this 타입 정보(<T extends MatcherState = MatcherState>)가 객체 리터럴의 문맥적 타입으로 전달되지 않기 때문이다.

따라서, 실제 this는 말 그대로 MatchersObject로 추론된다. (아마 함수 오버로딩으로 모듈을 많이 만들어본 경험이 있다면, 함수 시그니쳐를 매핑할 때 비슷한 이슈를 많이 겪어보았을 것이다)

즉, typescript가 this를 적절히 추론할 수 있도록 플래그를 추가해주면 된다.

3. 회귀 테스트

기존 테스트코드를 뒤져봤지만, 해당 케이스에 적용하기 적절한 타입 추론 테스트가 없었다. 리뷰 과정에서 아래의 코드로 퉁치는 것으로 마무리했다.

toBeTestedMatcherContext<T>(received: unknown, expected: T) {
  if (typeof this.utils?.stringify !== 'function') {
    throw new TypeError('this.utils.stringify is not available.')
  }
  return {
    pass: received === expected,
    message: () => 'toBeTestedMatcherContext',
  }
},

4. 해결

위에서 언급한대로 this가 적절히 추론되도록 플래그만 추가해주면 된다. 마침, 일전에 상태관리 코어모듈의 this타입(도메인 아톰)에 대한 타입추론 이슈를 겪어본 적이 있었어서 그때 사용했던 ThisType 유틸 함수를 사용해서 쉽게 해결할 수 있었다.

[Typescript Docs] ThisType<T>

export type MatchersObject<T extends MatcherState = MatcherState> = Record<
  string,
  RawMatcherFn<T>
> & ThisType<T> // ⛳️ ThisType 플래그 추가

5. Merged

vitest에 다시 기여를 진행한 건 거의 9개월만이다. PR에 대한 피드백 주기 및 방향성 제안 등에 모종의 불편함을 많이 느꼈었기 때문이다.

playwright 위주로 기여를 진행해왔지만, 이제 playwright 코어모듈의 expect나 test runner의 피쳐 및 버그를 거의 다 해결한 상태이기에 다시 vitest를 기웃거리게 되었다.

9개월 전보다 실력도 많이 올라왔고, vitest의 코드 리뷰 방식도 조금 바뀐 것 같아서 (당시엔 기여자가 많이 적어서 그랬나보다) 다시 vitest에 조금씩 기여를 진행하고자 한다.

SplayTree의 자료구조 특성상 학습 입문자용 가이드가 전혀 없었다. 혹시, 필요한 사람들이 있을까하여 하나 남겨두고자 한다.

1. 트리(Tree)

트리의 구성요소는 아래와 같다.

• node: 트리의 기본단위. 데이터와 자식 노드의 포인터를 가짐.
• root: 트리 최상단 노드
• leaf: 자식이 없는 노드
  각 노드는 0개 이상의 자식을 가지며, 자식은 하나의 부모노드를 가짐.

class Node {
  children = [];

  constructor(value) {
    this.value = value;
  }
}

import { Node } from './tree/node';

const root = new Node(1); // root node
// root node의 자식 노드(2번째 노드) 추가
root.children.push(new Node(2));
// root node의 자식 노드(3번째 노드) 추가
root.children.push(new Node(3));
// root node의 자식 노드(2번째 노드)의 자식 노드(4번째 노드) 추가
root.children[0].children.push(new Node(4));


console.log(root);
/**
 *  Node {
 *    value: 1,
 *    children: [
 *      Node {
 *        value: 2,
 *        children: [ Node { value: 4, children: [] }
 *     },
 *     Node { value: 3, children: [] }
 *   ]
 * }
 */

• 노드는 여러 자식을 가질 수 있음.
• 다만, 보통 문제에선 이진트리를 많이 사용.

2. 이진트리(Binary Tree)

• 각 노드가 최대 2개의 자식(right, left)을 갖는 트리.

3. 이진 탐색 트리(Binary Search Tree)

거기서 검색을 빠르게 함. 근데 빠르게 검색하기 위해서 조건을 좀 붙임.

• 각각의 노드는 왼쪽 서브트리의 모든 값은 노드의 값보다 작고, 오른쪽 서브트리의 모든 값은 노드의 값보다 큼.

이러면 검색뿐 아니라 삽입, 삭제 연산을 O(logN)으로 땡길 수 있음.

class BSTNode {
  left = null; // 왼쪽 자식
  right = null; // 오른쪽 자식
  parent = null; // optional. 다만, 추후 splayTree 개념 확장을 위해 추가

  constructor(value) {
    this.value = value;
  }
}

class BinarySearchTree {
  root = null;

  // 삽입 O(logN)
  insert(value) {
    const newNode = new BSTNode(value);
    if (!this.root) {
      this.root = newNode;
      return newNode;
    }
    let cur = this.root;
    let parent = null;
    while (cur) {
      parent = cur;
      if (value < cur.value) cur = cur.left;
      else cur = cur.right;
    }
    newNode.parent = parent;
    if (value < parent.value) parent.left = newNode;
    else parent.right = newNode;
    return newNode;
  }

  // 탐색 O(logN)
  find(value) {
    let cur = this.root;
    while (cur) {
      if (cur.value === value) return cur;
      else if (value < cur.value) cur = cur.left;
      else cur = cur.right;
    }
    return null;
  }
}

const bst = new BinarySearchTree();
bst.insert(10);
bst.insert(5);
bst.insert(15);
console.log(bst.find(15));
/**
 * BSTNode {
 *  value: 15,
 *  left: null,
 *  right: null,
 *  parent: BSTNode {
 *   value: 10,
 *   left: BSTNode { value: 5, left: null, right: null, parent: [BSTNode] },
 *   right: BSTNode { value: 15, left: null, right: null, parent: [BSTNode] }
 *  }
 * }
 */

• BST는 정렬된 순서로 데이터 저장. 이진탐색과 비슷하게 동작
• 부모 포인터가 왜 있는가? < SplayTree와 같은 자기 조정 트리에서 써야함.

4. 근데 막 회전함

회전(Rotation)은 두 노드 간의 관계를 재조정하는 연산임

• 좌측 회전: 오른쪽 자식을 루트로 끌어올림.
• 우측 회전: 왼쪽 자식을 루트로 끌어올림.

근데 얘 왜 돎?:

• 자주 접근하는 노드가 루트에 가깝게 조정되서, 접근시간 단축됨

const rotate = (x, dir) => {
  const p = x.parent;
  if (!p) return; // root node인 경우 회전 불가
  if (dir === 'right') {
    p.left = x.right;
    if (x.right) x.right.parent = p;
    x.right = p;
  } else {
    p.right = x.left;
    if (x.left) x.left.parent = p;
    x.left = p;
  }
  x.parent = p.parent;
  if (p.parent) {
    if (p.parent.left === p) p.parent.left = x;
    else p.parent.right = x;
  }
  p.parent = x;
};

그냥 차이점 개행으로 분리하자면

const Rotate = {
  right(x) {
    const p = x.parent;
    if (!p) return; // root node인 경우 회전 불가

    p.left = x.right;
    if (x.right) x.right.parent = p;
    x.right = p;

    x.parent = p.parent;
    if (p.parent) {
      if (p.parent.left === p) p.parent.left = x;
      else p.parent.right = x;
    }
    p.parent = x;
  },

  left(x) {
    const p = x.parent;
    if (!p) return; // root node인 경우 회전 불가

    p.right = x.left;
    if (x.left) x.left.parent = p;
    x.left = p;

    x.parent = p.parent;
    if (p.parent) {
      if (p.parent.left === p) p.parent.left = x;
      else p.parent.right = x;
    }
    p.parent = x;
  },
};

Splay Tree

이 친구는 특정 노드에 접근할 때마다 해당 노드를 루트로 끌어올림(자기 조정 트리)

splay 연산:

흥이 넘치는 연산이 3개 있음.

• zig: 노드 부모가 루트일 때, 단순 회전.

• zig-zig: 노드와 부모가 같은 방향일 때, 부모가 먼저 회전 > 이후 노드 회전.
• zig-zag: 노드와 부모가 반대 방향일 때, 회전 2배 이벤트 (2번 연속 회전)

Impl

class SplayNode {
  left = null;
  right = null;
  parent = null;

  constructor(value) {
    this.value = value;
  }
}

노드는 아까 BST랑 동일.

class SplayTree {
  root = null;

  rotate(x) {
    const p = x.parent;
    if (!p) return; // 루트 노드는 회전할 수 없음
    const g = p.parent;
    if (p.left === x) {
      // 우측 회전
      p.left = x.right;
      if (x.right) x.right.parent = p;
      x.right = p;
    } else {
      // 좌측 회전
      p.right = x.left;
      if (x.left) x.left.parent = p;
      x.left = p;
    }
    p.parent = x;
    x.parent = g;
    if (g) {
      if (g.left === p) g.left = x;
      else g.right = x;
    } else {
      this.root = x;
    }
  }

  splay(x) {
    if (!x) return; // 노드가 없으면 종료
    while (x.parent) {
      const p = x.parent;
      const g = p.parent;

      const isZig = !g;
      const isZigZig =
        (g && g.left === p && p.left === x) || (g.right === p && p.right === x);

      // 3가지 회전 케이스
      if (isZig) {
        // zig
        this.rotate(x);
      } else if (isZigZig) {
        // zig-zig
        this.rotate(p);
        this.rotate(x);
      } else {
        // zig-zag
        this.rotate(x);
        this.rotate(x);
      }
    }
    this.root = x;
  }

  // 삽입: BST 삽입 후, 해당 노드 루트로 splay
  insert(value) {
    const newNode = new SplayNode(value);
    if (!this.root) {
      this.root = newNode;
      return newNode;
    }
    let cur = this.root;
    let parent = null;
    while (cur) {
      parent = cur;
      if (value < cur.value) cur = cur.left;
      else cur = cur.right;
    }
    newNode.parent = parent;
    if (value < parent.value) parent.left = newNode;
    else parent.right = newNode;
    this.splay(newNode);
    return newNode;
  }

  // 검색: value 찾고, 해당 노드 루트로 splay
  find(value) {
    let cur = this.root;
    while (cur) {
      if (cur.value === value) {
        this.splay(cur);
        return cur;
      } else if (value < cur.value) {
        cur = cur.left;
      } else {
        cur = cur.right;
      }
    }
    return null;
  }
}

SplayTree 문제들

> 배웠으면 헤딩

C++로 보기 좋은 자료

PR issue#31249

Input에 대해 input validity기반 a11y 요소 기반 테스트 메서드인 expect(locator).toHaveAccessibleErrorMessage()를 추가해달라는 요청이었다.

3주 동안 w3c 스펙을 기반으로 에러 메시지를 반환하는 경우의 정의에 대한 토론과 추상화 및 피드백을 진행하였다.

2. Context 파악

요구사항이 생각보다 많이 복잡했다. 추상화를 진행하기 전, 아래의 것들을 파악했다.

1. w3c Spec
2. 다른 라이브러리의 추상화 방식

aria 속성과 에러메시지를 사용하여 이를 해결하려 했지만, maintainer님이 Input Validity의 속성도 파악하시길 원했다.

올바른 role 파악 > aria-invalid 필드기반 토큰 반환 > inputValidity 파악 > 둘 중 문제가 하나라도 있는 경우 유효하지 않는 상태로 파악

3주 동안 추상화 방식와 테스트코드가 계속 변하였고 최종적으로 나오게된 피쳐는 아래와 같다.

3. 테스트 코드

TC에 대한 오버헤드를 우려해 엣지케이스에 대한 테스트들은 전부 확인한 뒤 제거한 코드이다.

에러 메시지가 여러개인 경우, aria-invalid가 반환하는 여러가지 토큰들, inputValidity 자체의 값. 이것들이 errorMessage를 반환하는 의사결정의 분기에 의존성이 있어 단순히 머릿속으로 이해한 뒤 추상화 하기엔 조금 어려웠다. 머리를 오래 쓰기 싫어서 Spec 및 토의결과 기반으로 TDD를 진행했고, 오랜만에 그것의 효용성을 느끼게 되었다. (복잡한 Spec 및 많은 의사결정 분기 기반 피쳐는 TDD가 확실히 편한듯 하다)

test('toHaveAccessibleErrorMessage', async ({ page }) => {
  await page.setContent(`
    <form>
      <input role="textbox" aria-invalid="true" aria-errormessage="error-message" />
      <div id="error-message">Hello</div>
      <div id="irrelevant-error">This should not be considered.</div>
    </form>
  `);

  const locator = page.locator('input[role="textbox"]');
  await expect(locator).toHaveAccessibleErrorMessage('Hello');
  await expect(locator).not.toHaveAccessibleErrorMessage('hello');
  await expect(locator).toHaveAccessibleErrorMessage('hello', { ignoreCase: true });
  await expect(locator).toHaveAccessibleErrorMessage(/ell\w/);
  await expect(locator).not.toHaveAccessibleErrorMessage(/hello/);
  await expect(locator).toHaveAccessibleErrorMessage(/hello/, { ignoreCase: true });
  await expect(locator).not.toHaveAccessibleErrorMessage('This should not be considered.');
});

test('toHaveAccessibleErrorMessage should handle multiple aria-errormessage references', async ({ page }) => {
  await page.setContent(`
    <form>
      <input role="textbox" aria-invalid="true" aria-errormessage="error1 error2" />
      <div id="error1">First error message.</div>
      <div id="error2">Second error message.</div>
      <div id="irrelevant-error">This should not be considered.</div>
    </form>
  `);

  const locator = page.locator('input[role="textbox"]');

  await expect(locator).toHaveAccessibleErrorMessage('First error message. Second error message.');
  await expect(locator).toHaveAccessibleErrorMessage(/first error message./i);
  await expect(locator).toHaveAccessibleErrorMessage(/second error message./i);
  await expect(locator).not.toHaveAccessibleErrorMessage(/This should not be considered./i);
});

test.describe('toHaveAccessibleErrorMessage should handle aria-invalid attribute', () => {
  const errorMessageText = 'Error message';

  async function setupPage(page, ariaInvalidValue: string | null) {
    const ariaInvalidAttr = ariaInvalidValue === null ? '' : `aria-invalid="${ariaInvalidValue}"`;
    await page.setContent(`
        <form>
          <input id="node" role="textbox" ${ariaInvalidAttr} aria-errormessage="error-msg" />
          <div id="error-msg">${errorMessageText}</div>
        </form>
      `);
    return page.locator('#node');
  }

  test.describe('evaluated in false', () => {
    test('no aria-invalid attribute', async ({ page }) => {
      const locator = await setupPage(page, null);
      await expect(locator).not.toHaveAccessibleErrorMessage(errorMessageText);
    });
    test('aria-invalid="false"', async ({ page }) => {
      const locator = await setupPage(page, 'false');
      await expect(locator).not.toHaveAccessibleErrorMessage(errorMessageText);
    });
    test('aria-invalid="" (empty string)', async ({ page }) => {
      const locator = await setupPage(page, '');
      await expect(locator).not.toHaveAccessibleErrorMessage(errorMessageText);
    });
  });
  test.describe('evaluated in true', () => {
    test('aria-invalid="true"', async ({ page }) => {
      const locator = await setupPage(page, 'true');
      await expect(locator).toHaveAccessibleErrorMessage(errorMessageText);
    });
    test('aria-invalid="foo" (unrecognized value)', async ({ page }) => {
      const locator = await setupPage(page, 'foo');
      await expect(locator).toHaveAccessibleErrorMessage(errorMessageText);
    });
  });
});

test.describe('toHaveAccessibleErrorMessage should handle validity state with aria-invalid', () => {
  const errorMessageText = 'Error message';

  test('should show error message when validity is false and aria-invalid is true', async ({ page }) => {
    await page.setContent(`
      <form>
        <input id="node" role="textbox" type="number" min="1" max="100" aria-invalid="true" aria-errormessage="error-msg" />
        <div id="error-msg">${errorMessageText}</div>
      </form>
    `);
    const locator = page.locator('#node');
    await locator.fill('101');
    await expect(locator).toHaveAccessibleErrorMessage(errorMessageText);
  });

  test('should show error message when validity is true and aria-invalid is true', async ({ page }) => {
    await page.setContent(`
      <form>
        <input id="node" role="textbox" type="number" min="1" max="100" aria-invalid="true" aria-errormessage="error-msg" />
        <div id="error-msg">${errorMessageText}</div>
      </form>
    `);
    const locator = page.locator('#node');
    await locator.fill('99');
    await expect(locator).toHaveAccessibleErrorMessage(errorMessageText);
  });

  test('should show error message when validity is false and aria-invalid is false', async ({ page }) => {
    await page.setContent(`
      <form>
        <input id="node" role="textbox" type="number" min="1" max="100" aria-invalid="false" aria-errormessage="error-msg" />
        <div id="error-msg">${errorMessageText}</div>
      </form>
    `);
    const locator = page.locator('#node');
    await locator.fill('101');
    await expect(locator).toHaveAccessibleErrorMessage(errorMessageText);
  });

  test('should not show error message when validity is true and aria-invalid is false', async ({ page }) => {
    await page.setContent(`
      <form>
        <input id="node" role="textbox" type="number" min="1" max="100" aria-invalid="false" aria-errormessage="error-msg" />
        <div id="error-msg">${errorMessageText}</div>
      </form>
    `);
    const locator = page.locator('#node');
    await locator.fill('99');
    await expect(locator).not.toHaveAccessibleErrorMessage(errorMessageText);
  });
});

4. 추상화

> role Util

Maintainer님의 의견에 따라 utils에 로직을 분리하고 기존 컨벤션대로 로직 추가

Role Utils

// https://www.w3.org/TR/wai-aria-1.2/#aria-invalid
const kAriaInvalidRoles = ['application', 'checkbox', 'combobox', 'gridcell', 'listbox', 'radiogroup', 'slider', 'spinbutton', 'textbox', 'tree', 'columnheader', 'rowheader', 'searchbox', 'switch', 'treegrid'];

function getAriaInvalid(element: Element): 'false' | 'true' | 'grammar' | 'spelling' {
  const role = getAriaRole(element) || '';
  if (!role || !kAriaInvalidRoles.includes(role))
    return 'false';
  const ariaInvalid = element.getAttribute('aria-invalid');
  if (!ariaInvalid || ariaInvalid.trim() === '' || ariaInvalid.toLocaleLowerCase() === 'false')
    return 'false';
  if (ariaInvalid === 'true' || ariaInvalid === 'grammar' || ariaInvalid === 'spelling')
    return ariaInvalid;
  return 'true';
}

function getValidityInvalid(element: Element) {
  if ('validity' in element){
    const validity = element.validity as ValidityState | undefined;
    return validity?.valid === false;
  }
  return false;
}

export function getElementAccessibleErrorMessage(element: Element): string {
  // SPEC: https://w3c.github.io/aria/#aria-errormessage
  //
  // TODO: support https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/validationMessage
  const cache = cacheAccessibleErrorMessage;
  let accessibleErrorMessage = cacheAccessibleErrorMessage?.get(element);

  if (accessibleErrorMessage === undefined) {
    accessibleErrorMessage = '';

    const isAriaInvalid = getAriaInvalid(element) !== 'false';
    const isValidityInvalid = getValidityInvalid(element);
    if (isAriaInvalid || isValidityInvalid) {
      const errorMessageId = element.getAttribute('aria-errormessage');
      const errorMessages = getIdRefs(element, errorMessageId);
      // Ideally, this should be a separate "embeddedInErrorMessage", but it would follow the exact same rules.
      // Relevant vague spec: https://w3c.github.io/core-aam/#ariaErrorMessage.
      const parts = errorMessages.map(errorMessage => asFlatString(
          getTextAlternativeInternal(errorMessage, {
            visitedElements: new Set(),
            embeddedInDescribedBy: { element: errorMessage, hidden: isElementHiddenForAria(errorMessage) },
          })
      ));
      accessibleErrorMessage = parts.join(' ').trim();
    }
    cache?.set(element, accessibleErrorMessage);
  }
  return accessibleErrorMessage;
}

Method

export function toHaveAccessibleErrorMessage(
  this: ExpectMatcherState,
  locator: LocatorEx,
  expected: string | RegExp,
  options?: { timeout?: number; ignoreCase?: boolean },
) {
  return toMatchText.call(this, 'toHaveAccessibleErrorMessage', locator, 'Locator', async (isNot, timeout) => {
    const expectedText = serializeExpectedTextValues([expected], { ignoreCase: options?.ignoreCase, normalizeWhiteSpace: true });
    return await locator._expect('to.have.accessible.error.message', { expectedText: expectedText, isNot, timeout });
  }, expected, options);
}

3주간 리뷰. 그리고 merged

말한대로 3주 동안 추상화 방식, 에러 판단 방식 등 계속해서 변경되었다.

추상화 > 리뷰 요청 > 피드백 > ... 반복 > merged

3주 간의 41개의 커뮤니케이션 끝에 merged 되었다.

• maintainer님들에게 조금 죄송한 마음이 드는 PR이었다. 필자가 영어를 더 잘했고 공식 Spec을 어느정도 잘 숙지하고 있었다면 maintainer의 시간을 덜 뺐었을 수 있었을텐데...🥲 (공식문서 버젼별로 스펙이 조금씩 달랐던 부분이라 다른 문서를 보고 잘못 추상화 한 경우도 있었고, 영어 잘못 해석해서 추상화를 잘못한 경우도 있었다. 🥲)

그래도 공식 스펙과 버젼을 인지하고 추상화하는 연습을 잘 할 수 있었던 PR이라 다음엔 더 나은 코드로 보답하는걸로...!

Deploy 1.50

> Docs > Spec

issue #24232

토의가 활발히 일어났던 이슈.

GenericAssertions에 두 가지 메서드를 추가해달라는 요청이다. 해당 기능이 제공된다면, 조금 더 간단하고 직관적으로 여러 상황에 따른 case들을 테스트에서 핸들링할 수 있다.

두 개의 메서드를 전부 구현해 PR을 무겁게 생성하기보단, toBeOneOf를 먼저 추상화 한 후 PR > 리뷰 > merged > follow-PR 방식이 구현 및 리뷰자 관점에서 효율적이라 판단했다.

2. Context 파악

코드 보기

matchers.ts에 여러 GenericAssertions들이 외부 모듈(jest)에 의존성을 강하게 가진 상태로 제공되고 있는 상태이다.

// ex) MatchersObject.toBe()
const matchers: MatchersObject = {
  toBe(received: unknown, expected: unknown) {
    const matcherName = 'toBe';
    const options: MatcherHintOptions = {
      comment: 'Object.is equality',
      isNot: this.isNot,
      promise: this.promise,
    };

    const pass = Object.is(received, expected);

    const message = pass
      ? () =>

        matcherHint(matcherName, undefined, undefined, options) +
        '\n\n' +
        `Expected: not ${printExpected(expected)}`
      : () => {
        const expectedType = getType(expected);

        let deepEqualityName = null;
        if (expectedType !== 'map' && expectedType !== 'set') {
          // If deep equality passes when referential identity fails,
          // but exclude map and set until review of their equality logic.
          if (
            equals(
                received,
                expected,
                [...this.customTesters, ...toStrictEqualTesters],
                true,
            )
          )
            deepEqualityName = 'toStrictEqual';
          else if (
            equals(received, expected, [
              ...this.customTesters,
              iterableEquality,
            ])
          )
            deepEqualityName = 'toEqual';

        }

        return (

          matcherHint(matcherName, undefined, undefined, options) +
          '\n\n' +
          (deepEqualityName !== null
            ? `${DIM_COLOR(
                `If it should pass with deep equality, replace "${matcherName}" with "${deepEqualityName}"`,
            )}\n\n`
            : '') +
          printDiffOrStringify(
              expected,
              received,
              EXPECTED_LABEL,
              RECEIVED_LABEL,
              isExpand(this.expand),
          )
        );
      };

    // Passing the actual and expected objects so that a custom reporter
    // could access them, for example in order to display a custom visual diff,
    // or create a different error message
    return { actual: received, expected, message, name: matcherName, pass };
  },

어떤 방식으로 API를 제공하는지 파악하고 docs를 읽어 금방 context를 파악할 수 있었다.

3. 회귀 테스트 추가

기존 TC와는 컨벤션이 많이 다른 것을 알 수 있다. 해당 모듈은 애초에 third-party 모듈로 구분되어, 가독성보단 다양한 테스트케이스를 적용해 엣지 케이스를 최소화 하는 것을 목표로 두는 것 같았다.

• playwright의 자체 API는 테스트 환경 구동에서 꽤 많은 리소스와 시간을 잡아먹는다. 그렇기에 테스트양이 많아질수록 오버헤드가 발생하는 것을 경계하라는 피드백을 받은 적이 있었다.
  다만, third-party 외부 라이브러리 테스트는 로컬에서 자체적인 빌드 후 커밋과 함께 스냅샷을 비교하는 테스트로 진행되고 있었다. (npm run ttest에서 1000번 후반대 테스트 진행 후 갑자기 1000개 가량이 짧은 시간 안에 실행되는 테스트)

가독성이 떨어지는 건 알지만, 테스트 컨벤션이 아래와 같아 비슷하게 적용하였다.

test.describe('.toBeOneOf()', () => {
  const matchingCases = [
    [2, [1, 2, 3]],
    ['b', ['a', 'b', 'c']],
    [true, [false, true]],
    [null, [undefined, null]],
    [undefined, [undefined, null]],
    [NaN, [NaN, 1, 2]],
    [BigInt(1), [BigInt(1), BigInt(2)]],
    [[1, 2], [[1, 2], [3, 4]]],
    [{ a: 1 }, [{ a: 1 }, { b: 2 }]],
    [{ a: { b: { c: 1 } } }, [{ a: { b: { c: 1 } } }, { a: { b: { c: 2 } } }]],
  ];

  const nonMatchingCases = [
    [4, [1, 2, 3]],
    ['d', ['a', 'b', 'c']],
    [false, [true]],
    [null, [undefined]],
    [undefined, [null]],
    [NaN, [1, 2]],
    [BigInt(3), [BigInt(1), BigInt(2)]],
    [[1, 2], [[3, 4], [5, 6]]],
    [{ a: 1 }, [{ b: 2 }, { c: 3 }]],
    [{ a: { b: { c: 1 } } }, [{ a: { b: { c: 2 } } }]],
  ];

  matchingCases.forEach(([value, array]: [any, any]) => {
    test(`passes when the value is in the expected array: expect(${stringify(value)}).toBeOneOf(${stringify(array)})`, () => {
      expectUnderTest(value).toBeOneOf(array);
    });
  });

  nonMatchingCases.forEach(([value, array]: [any, any]) => {
    test(`fails when the value is not in the expected array: expect(${stringify(value)}).toBeOneOf(${stringify(array)})`, () => {
      expect(() => expectUnderTest(value).toBeOneOf(array)).toThrowErrorMatchingSnapshot();
    });
  });

  nonMatchingCases.forEach(([value, array]: [any, any]) => {
    test(`passes when using .not and value is not in the expected array: expect(${stringify(value)}).not.toBeOneOf(${stringify(array)})`, () => {
      expectUnderTest(value).not.toBeOneOf(array);
    });
  });

  matchingCases.forEach(([value, array]: [any, any]) => {
    test(`fails when using .not and value is in the expected array: expect(${stringify(value)}).not.toBeOneOf(${stringify(array)})`, () => {
      expect(() => expectUnderTest(value).not.toBeOneOf(array)).toThrowErrorMatchingSnapshot();
    });
  });

  test('supports asymmetric matchers within the expected array', () => {
    expectUnderTest({ a: 1, b: 2 }).toBeOneOf([
      { a: 1 },
      expect.objectContaining({ b: 2 }),
    ]);
    expectUnderTest('hello world').toBeOneOf([
      expect.stringContaining('world'),
      'hello',
    ]);
  });

  test('fails when value does not match any asymmetric matchers in expected array', () => {
    expect(() =>
      expectUnderTest({ a: 1, b: 2 }).toBeOneOf([
        { a: 2 },
        expect.objectContaining({ c: 3 }),
      ]),
    ).toThrowErrorMatchingSnapshot();
  });

  test('assertion error matcherResult property contains matcher name, expected and actual values', () => {
    const actual = 5;
    const expected = [1, 2, 3];
    try {
      expectUnderTest(actual).toBeOneOf(expected);
    } catch (error) {
      expect(error.matcherResult).toEqual(
          expect.objectContaining({
            actual,
            expected,
            name: 'toBeOneOf',
          }),
      );
    }
  });
});

4. 구현 및 문서작성

  toBeOneOf(received: unknown, expected: Array<unknown>) {
    const matcherName = 'toBeOneOf';
    const isNot = this.isNot;
    const options: MatcherHintOptions = {
      isNot,
      promise: this.promise,
    };

    if (!Array.isArray(expected)) {
      throw new Error(
          matcherErrorMessage(
              matcherHint(matcherName, undefined, undefined, options),
              `${EXPECTED_COLOR('expected')} value must be an array`,
              printWithType('Expected', expected, printExpected),
          ),
      );
    }

    // ⛳️ Nested된 참조데이터용 deepEquals 알고리즘
    const pass = expected.some(item =>
      equals(received, item, [...this.customTesters, iterableEquality]),
    );

    const message = () =>
      matcherHint(matcherName, undefined, undefined, options) +
      '\n\n' +
      `Expected: ${isNot ? 'not ' : ''}to be one of ${printExpected(expected)}\n` +
      `Received: ${printReceived(received)}`;

    // ⛳️ 일부 메서드에선 pass, message만 제공하였으나, 확장성 있는 컨벤션 따르기로 함.
    return { actual: received, expected, message, name: matcherName, pass };
  },

## method: GenericAssertions.toBeOneOf
* since: v1.49.1

Ensures that value is deeply equal to one of the elements in the expected array.

**Usage**

'''js
const value = 2;
expect(value).toBeOneOf([1, 2, 3]);
expect(value).not.toBeOneOf([4, 5, 6]);

const obj = { a: 1 };
expect(obj).toBeOneOf([{ a: 1 }, { b: 2 }]);
expect(obj).not.toBeOneOf([{ a: 2 }, { b: 3 }]);
'''

### param: GenericAssertions.toBeOneOf.expected
* since: v1.49.1
- `expected` <[Array]<[any]>>

Expected array to match against.

5. PR 및 Issue Closed

> PR

구현하면서 조금 오래된 Issue이고 GenericAssertions가 1.9v이 업데이트되며, 최초에 제기된 issue를 해결할 수 있는 몇 가지 메서드가 추가되었다. 이를 뒤늦게 인지한 것은 구현이 끝난 뒤 문서작업 컨벤션을 확인하는 과정이었다.

그래도 기능 자체는 다르기 때문에, 굳이 Issue창에서 묻는 것보단 PR을 남겨두고 피드백을 받는게 낫다고 판단하였다.

오픈소스 팀이 워낙 바쁘다보니 오래된 issue가 관리되지 않았던 것이다. 팀 내 토의를 통해, playwright에 해당 API를 지원하지 않으시는 것이 결론났고, PR은 closed되었다.

처음엔 조금 아쉬움이 들었다.(노력했으나 결과가 나오지 않았다고 생각했던 것 같다.) 문득, 감정을 복기하다보니 몇 가지들을 깨닫게 되었고, 오히려 본질적인 기여에 한 걸음 다가갔다는 생각이 들기 시작했다.

6. 기여의 본질?

우리는 종종 형태에 집착한다. 형태에 집착하면, 이는 우리의 눈을 가리고 본질을 보지 못하게 한다.

PR이 closed 되었을 때, 느껴진 아쉬움에서 내가 오픈소스에 가지고 있던 태도를 추론할 수 있었다.

• docs가 아닌 feat, fix에 대한 기여를 높이 평가하거나, Contribute 후 프로필 창에 기여 표시. 즉, 기여의 형태에 집착하고 있었던 것이다.

물론, 이렇게 진행한 기여 또한 멋진 기여임에는 틀림이 없지만, 필자가 도달하고자 하는 이상적인 오픈소스 활동과는 거리가 있었다.

필자가 이루고자 하는 이상적인 기여란 단순히 내가 작성한 코드의 병합을 의미하지 않았다.

하나의 오픈소스에 꾸준히 활동하며 하나의 팀이 되어가는 것. PR이나 issue를 통해 피드백 받고, 토의하고, 팀의 컨벤션과 철학을 알아가며, 때로는 현재 PR처럼 팀들이 신경쓰지 못하는 부분을 서포팅 해주는 것이 진정한 하나의 팀. 그리고 기여가 되어가는 과정이라고 생각하기 때문이다.

쉽게 말해 필자가 생각하는 "기여"란 팀에 도움이 되었고 모종의 가치를 창출했다면 그걸로 OK라는 것이다.

즉, playwright 팀이 신경쓰지 못했던 부분을 PR을 통해 팀 토의로 이끌고, issue를 close 하였다는 그 자체가 멋진 기여라고 생각되었다.

나는 처음이지만, maintainer는 아닐껄?

분명, 오픈소스 maintainer들은 이런 상황(PR Close)에 직면한 적이 여러번 존재할 것이다. PR이 Closed 된다면 그 기여자가 다시 해당 프로젝트에 기여할 확률이 줄어든다는 것을 그들은 경험적으로 알 것이라 생각된다. 거절은 종종 상처로 다가오기 때문이다.

오픈소스 maintainer들은 기여자의 감정적인 부분들까지 신경써줘야 한다는 것을 깨닫고, 그들이 짊어진 무게를 조금 더 알게 되었다.

몇몇 오픈소스에는 기여 과정에서 아쉬웠던 부분들이 종종 존재했으나, 가장 즐거운 기여 경험은 playwright라고 장담할 수 있다. 멋진 팀의 일원이 될 수 있기를 바란다.

issue #29382

toHaveText 매개변수로 정규표현식 담긴 배열 넘기면 맞아도 틀렸다 뜨는 문제.

쉬워보이는데 왜 열린지 9개월째 해결이 안됐을까? 아래의 사진(번역)이 그 이유를 알려준다.

diff의 message를 print하는 로직은 외부 유틸함수(jest)에 위임된 상태여서 내부 diff 로직이 사용자에게 커스텀 matcher(diff로직) API를 제공하지 않는다면 해결하기 어려운 문제라고 언급해서 그런듯하다.

필자는 vitest쪽에서 비대칭 매처쪽 코드를 많이 봤었기 때문에, 이번에도 일단 헤딩 시작!

2. Context 파악

1. 코드보기

export function toHaveText(
  this: ExpectMatcherState,
  locator: LocatorEx,
  expected: string | RegExp | (string | RegExp)[],
  options: { timeout?: number, useInnerText?: boolean, ignoreCase?: boolean } = {},
) {
  // ⛳️ 1. 배열인 경우니까.
  if (Array.isArray(expected)) {
    // ⛳️ 2. toEqual 먼저 따보기 됨.
    return toEqual.call(this, 'toHaveText', locator, 'Locator', async (isNot, timeout) => {
      const expectedText = serializeExpectedTextValues(expected, { normalizeWhiteSpace: true, ignoreCase: options.ignoreCase });
      return await locator._expect('to.have.text.array', { expectedText, isNot, useInnerText: options?.useInnerText, timeout });
    }, expected, options);
  } else {
    return toMatchText.call(this, 'toHaveText', locator, 'Locator', async (isNot, timeout) => {
      const expectedText = serializeExpectedTextValues([expected], { normalizeWhiteSpace: true, ignoreCase: options.ignoreCase });
      return await locator._expect('to.have.text', { expectedText, isNot, useInnerText: options?.useInnerText, timeout });
    }, expected, options);
  }
}

2. toEqual 확인

   export async function toEqual<T>(
   this: ExpectMatcherState,
   matcherName: string,
   receiver: Locator,
   receiverType: string,
   query: (isNot: boolean, timeout: number) => Promise<{ matches: boolean, received?: any, log?: string[], timedOut?: boolean }>,
   expected: T,
   options: { timeout?: number, contains?: boolean } = {},
   ): Promise<MatcherResult<any, any>> {
   expectTypes(receiver, [receiverType], matcherName);
   
   const matcherOptions = {
    comment: options.contains ? '' : 'deep equality',
    isNot: this.isNot,
    promise: this.promise,
   };
   
   const timeout = options.timeout ?? this.timeout;
   
   const { matches: pass, received, log, timedOut } = await query(!!this.isNot, timeout);
   if (pass === !this.isNot) {
    return {
      name: matcherName,
      message: () => '',
      pass,
      expected
    };
   }
   
   let printedReceived: string | undefined;
   let printedExpected: string | undefined;
   let printedDiff: string | undefined;
   if (pass) { // ⛳️ 1. 정규 표현식이 있으면 무조건 fail이니까
    printedExpected = `Expected: not ${this.utils.printExpected(expected)}`;
    printedReceived = `Received: ${this.utils.printReceived(received)}`;
   } else {
    // ⛳️ 2. 여기에 구현하면 끝남. 아래 코드는 외부 jest 유틸함수.
    // 즉, 외부 의존성 있는 유틸함수에 값 넘겨주기 전에, 정규화 해주면 해결되는 문제.
    // - 배열 여부 판단
    // - expect가 regex인 경우, received값이 expect의 regex에 match 될 경우, expect 값을 received로 변경시켜 외부 Diff 알고리즘에 통과하도록 조정해주면 됨.
    printedDiff = this.utils.printDiffOrStringify(
        expected,
        received,
        EXPECTED_LABEL,
        RECEIVED_LABEL,
        false,
    );
   }
   const message = () => {
    const header = matcherHint(this, receiver, matcherName, 'locator', undefined, matcherOptions, timedOut ? timeout : undefined);
    const details = printedDiff || `${printedExpected}\n${printedReceived}`;
    return `${header}${details}${callLogText(log)}`;
   };
   // Passing the actual and expected objects so that a custom reporter
   // could access them, for example in order to display a custom visual diff,
   // or create a different error message
   return {
    actual: received,
    expected, message,
    name: matcherName,
    pass,
    log,
    timeout: timedOut ? timeout : undefined,
   };
   }

3. 회귀 테스트 추가

이슈 내용 그대로 매개변수로 (string|RegExp)[] 넘겨줬을 때 regex가 match될 때 에러 안던지면 됨.

test('should only highlight unmatched regex in diff message for toHaveText with array', async ({ runInlineTest }) => {
  const result = await runInlineTest({
    'a.spec.ts': `
      import { test, expect } from '@playwright/test';
      test('toHaveText with mixed strings and regexes (array)', async ({ page }) => {
        await page.setContent(\`
          <ul>
            <li>Coffee</li>
            <li>Tea</li>
            <li>Milk</li>
          </ul>
        \`);
        const items = page.locator('li');
        await expect(items).toHaveText(['Coffee', /\\d+/, /Milk/]);
      });
    `,
  });
  expect(result.exitCode).toBe(1);
  const output = result.output;
  expect(output).toContain('-   /\\d+/,'); // 숫자값에 match되지 않았으니 에러 메시지에 있어야 함.
  expect(output).toContain('+   "Tea",'); // 위 regex랑 페어. 문자열이니 에러 메시지에 있어야 함.
  // 해당 유닛테스트의 본질. 내 코드가 있을때만, 아래의 테스트가 통과해야함.
  expect(output).not.toContain('-   /Milk/,'); // regex에 match되니 에러 메시지에 없어야 함.
  expect(output).not.toContain('-   "Coffee",'); // 그냥 기본으로 통과되어야 함.
});

4. 해결

if (pass) {
    printedExpected = `Expected: not ${this.utils.printExpected(expected)}`;
    printedReceived = `Received: ${this.utils.printReceived(received)}`;
  // ⛳️ 1. 배열 쌍인 경우 중,
  // (제네릭 타입이기 때문에 (string | RegExp)[]가 아닐 수 있으므로 분기처리)
  } else if (Array.isArray(expected) && Array.isArray(received)) {
    const normalizedExpected = expected.map((exp, index) => {
      const rec = received[index];
      // ⛳️ 2. received 값이 RegExp인 경우
      if (isRegExp(exp))
        // ⛳️ 3. expect의 값을 receive와 동일하게 변경
        // 커스텀 플래그("[match]")를 세울까 하다가 원본 값을 최대한 유지(rec => exp)하는 것으로 선택
        return exp.test(rec) ? rec : exp;

      return exp;
    });
    printedDiff = this.utils.printDiffOrStringify(
        // ⛳️ 4. 정규화된 expected 넘겨주기
        normalizedExpected,
        received,
        EXPECTED_LABEL,
        RECEIVED_LABEL,
        false,
    );
  } else {
    printedDiff = this.utils.printDiffOrStringify(
        expected,
        received,
        EXPECTED_LABEL,
        RECEIVED_LABEL,
        false,
    );
  }

5. PR 및 merged

간단한 변경사항 요청 후 merged

> PR #33533

issue #30662

test.fail.only 구현해주세요.

이슈창에서 1차 방향성 확인

2. Context 파악

1. testType이 추상화 된 파일을 찾아, 디깅. fail을 찾아 파일을 따라가보니, TestTypeImpl에 동작 방식이 추상화 되어있음. (아래 코드는 fail.only 추상화가 끝나있는 코드)

export class TestTypeImpl {
  readonly fixtures: FixturesWithLocation[];
  readonly test: TestType<any, any>;

  constructor(fixtures: FixturesWithLocation[]) {
    this.fixtures = fixtures;

    const test: any = wrapFunctionWithLocation(this._createTest.bind(this, 'default'));
    test[testTypeSymbol] = this;
    test.expect = expect;
    test.only = wrapFunctionWithLocation(this._createTest.bind(this, 'only'));
    test.describe = wrapFunctionWithLocation(this._describe.bind(this, 'default'));
    test.describe.only = wrapFunctionWithLocation(this._describe.bind(this, 'only'));
    test.describe.configure = wrapFunctionWithLocation(this._configure.bind(this));
    test.describe.fixme = wrapFunctionWithLocation(this._describe.bind(this, 'fixme'));
    test.describe.parallel = wrapFunctionWithLocation(this._describe.bind(this, 'parallel'));
    test.describe.parallel.only = wrapFunctionWithLocation(this._describe.bind(this, 'parallel.only'));
    test.describe.serial = wrapFunctionWithLocation(this._describe.bind(this, 'serial'));
    test.describe.serial.only = wrapFunctionWithLocation(this._describe.bind(this, 'serial.only'));
    test.describe.skip = wrapFunctionWithLocation(this._describe.bind(this, 'skip'));
    test.beforeEach = wrapFunctionWithLocation(this._hook.bind(this, 'beforeEach'));
    test.afterEach = wrapFunctionWithLocation(this._hook.bind(this, 'afterEach'));
    test.beforeAll = wrapFunctionWithLocation(this._hook.bind(this, 'beforeAll'));
    test.afterAll = wrapFunctionWithLocation(this._hook.bind(this, 'afterAll'));
    test.skip = wrapFunctionWithLocation(this._modifier.bind(this, 'skip'));
    test.fixme = wrapFunctionWithLocation(this._modifier.bind(this, 'fixme'));
    test.fail = wrapFunctionWithLocation(this._modifier.bind(this, 'fail'));
    test.fail.only = wrapFunctionWithLocation(this._createTest.bind(this, 'fail.only'));
    test.slow = wrapFunctionWithLocation(this._modifier.bind(this, 'slow'));
    test.setTimeout = wrapFunctionWithLocation(this._setTimeout.bind(this));
    test.step = this._step.bind(this);
    test.use = wrapFunctionWithLocation(this._use.bind(this));
    test.extend = wrapFunctionWithLocation(this._extend.bind(this));
    test.info = () => {
      const result = currentTestInfo();
      if (!result)
        throw new Error('test.info() can only be called while test is running');
      return result;
    };
    this.test = test;
  }

  private _currentSuite(location: Location, title: string): Suite | undefined {
    const suite = currentlyLoadingFileSuite();
    if (!suite) {
      throw new Error([
        `Playwright Test did not expect ${title} to be called here.`,
        `Most common reasons include:`,
        `- You are calling ${title} in a configuration file.`,
        `- You are calling ${title} in a file that is imported by the configuration file.`,
        `- You have two different versions of @playwright/test. This usually happens`,
        `  when one of the dependencies in your package.json depends on @playwright/test.`,
      ].join('\n'));
    }
    return suite;
  }

  private _createTest(type: 'default' | 'only' | 'skip' | 'fixme' | 'fail' | 'fail.only', location: Location, title: string, fnOrDetails: Function | TestDetails, fn?: Function) {
    throwIfRunningInsideJest();
    const suite = this._currentSuite(location, 'test()');
    if (!suite)
      return;

    let details: TestDetails;
    let body: Function;
    if (typeof fnOrDetails === 'function') {
      body = fnOrDetails;
      details = {};
    } else {
      body = fn!;
      details = fnOrDetails;
    }

    const validatedDetails = validateTestDetails(details);
    const test = new TestCase(title, body, this, location);
    test._requireFile = suite._requireFile;
    test._staticAnnotations.push(...validatedDetails.annotations);
    test._tags.push(...validatedDetails.tags);
    suite._addTest(test);

    if (type === 'only' || type === 'fail.only')
      test._only = true;
    if (type === 'skip' || type === 'fixme' || type === 'fail')
      test._staticAnnotations.push({ type });
    else if (type === 'fail.only')
      test._staticAnnotations.push({ type: 'fail' });
  }

  private _describe(type: 'default' | 'only' | 'serial' | 'serial.only' | 'parallel' | 'parallel.only' | 'skip' | 'fixme', location: Location, titleOrFn: string | Function, fnOrDetails?: TestDetails | Function, fn?: Function) {
    throwIfRunningInsideJest();
    const suite = this._currentSuite(location, 'test.describe()');
    if (!suite)
      return;

    let title: string;
    let body: Function;
    let details: TestDetails;

    if (typeof titleOrFn === 'function') {
      title = '';
      details = {};
      body = titleOrFn;
    } else if (typeof fnOrDetails === 'function') {
      title = titleOrFn;
      details = {};
      body = fnOrDetails;
    } else {
      title = titleOrFn;
      details = fnOrDetails!;
      body = fn!;
    }

    const validatedDetails = validateTestDetails(details);
    const child = new Suite(title, 'describe');
    child._requireFile = suite._requireFile;
    child.location = location;
    child._staticAnnotations.push(...validatedDetails.annotations);
    child._tags.push(...validatedDetails.tags);
    suite._addSuite(child);

    if (type === 'only' || type === 'serial.only' || type === 'parallel.only')
      child._only = true;
    if (type === 'serial' || type === 'serial.only')
      child._parallelMode = 'serial';
    if (type === 'parallel' || type === 'parallel.only')
      child._parallelMode = 'parallel';
    if (type === 'skip' || type === 'fixme')
      child._staticAnnotations.push({ type });

    for (let parent: Suite | undefined = suite; parent; parent = parent.parent) {
      if (parent._parallelMode === 'serial' && child._parallelMode === 'parallel')
        throw new Error('describe.parallel cannot be nested inside describe.serial');
      if (parent._parallelMode === 'default' && child._parallelMode === 'parallel')
        throw new Error('describe.parallel cannot be nested inside describe with default mode');
    }

    setCurrentlyLoadingFileSuite(child);
    body();
    setCurrentlyLoadingFileSuite(suite);
  }

  private _hook(name: 'beforeEach' | 'afterEach' | 'beforeAll' | 'afterAll', location: Location, title: string | Function, fn?: Function) {
    const suite = this._currentSuite(location, `test.${name}()`);
    if (!suite)
      return;
    if (typeof title === 'function') {
      fn = title;
      title = `${name} hook`;
    }

    suite._hooks.push({ type: name, fn: fn!, title, location });
  }

  // ... codes

  private _modifier(type: 'skip' | 'fail' | 'fixme' | 'slow', location: Location, ...modifierArgs: any[]) {
    const suite = currentlyLoadingFileSuite();
    if (suite) {
      if (typeof modifierArgs[0] === 'string' && typeof modifierArgs[1] === 'function' && (type === 'skip' || type === 'fixme' || type === 'fail')) {
        // Support for test.{skip,fixme,fail}(title, body)
        this._createTest(type, location, modifierArgs[0], modifierArgs[1]);
        return;
      }
      if (typeof modifierArgs[0] === 'string' && typeof modifierArgs[1] === 'object' && typeof modifierArgs[2] === 'function' && (type === 'skip' || type === 'fixme' || type === 'fail')) {
        // Support for test.{skip,fixme,fail}(title, details, body)
        this._createTest(type, location, modifierArgs[0], modifierArgs[1], modifierArgs[2]);
        return;
      }

      if (typeof modifierArgs[0] === 'function') {
        suite._modifiers.push({ type, fn: modifierArgs[0], location, description: modifierArgs[1] });
      } else {
        if (modifierArgs.length >= 1 && !modifierArgs[0])
          return;
        const description = modifierArgs[1];
        suite._staticAnnotations.push({ type, description });
      }
      return;
    }

    const testInfo = currentTestInfo();
    if (!testInfo)
      throw new Error(`test.${type}() can only be called inside test, describe block or fixture`);
    if (typeof modifierArgs[0] === 'function')
      throw new Error(`test.${type}() with a function can only be called inside describe block`);
    testInfo[type](...modifierArgs as [any, any]);
  }

  // ...codes
}

위 코드를 읽어보면, 몇 가지 특징을 알 수 있다.

1. Annotation 관리

nested 메서드를 동적으로 파싱해주는 줄 알았는데, 그냥 only는 _only필드로, 나머지 속성들은 _staticAnnotations에서 처리함을 알 수 있었다. (Annotation Type이 리터럴 유니온이 아닌 string이던데, 나중에 이슈 남기고 히스토리가 있는게 아니라면 PR 날릴 예정)

2. nested 메서드 추상화

Test 필드의 메서드의 메서드를 추상화하는 issue였기에 _describe 추상화 방식과, commit history에서 도움을 많이 받았다. 다만, 주의해야 하는게, describe는 test가 아닌 Suite(테스트 뭉치)이다. 즉, createTest와 공통점보다 차이점이 많아 별도의 메서드로 분리하여 사용(this._describe.bind)함을 알 수 있다. 적당히 보고 참고할 부분만 참고하자.

3. Type과 Docs는 빌드 타입에 생성된다

위 코드와는 관련이 없지만, playwright의 type 문서는 빌드 타임에 동적으로 생성된다. 다만, 이에 대한 문서 가이드가 없어서 조금 혼란을 겪었다. 어떻게 관리하는지 타입이 변경되는 커밋 히스토리를 까보면 되겠다싶어서 하나하나 까보다보니, utils/generate_types에서 관리되고 있었다.

이 부분에서 시간을 꽤 많이 허비했는데, 마침 이와 관련된 CONTRIBUTE 업데이트가 추가되었다.

문서를 읽고 간단한 검토를 남기다, type, docs에 대한 명시적 언급을 제안하였다. 문제는...

??? : 아니 이미 추가했잖아.

문서를 자세히 보니 해당 내용이 존재했다. 다만, 영어권이 아닌 사람들이 한 눈에 익히기에는 조금 하이라이팅이 부족하다고 느껴졌다. 뭔가 조금 죄송한 마음도 들어서 조용히 댓글로만 변경사항 제안을 남겨두었다.

3. 기능 구현

잠시 삼천포에 빠졌다. 다시 원래대로 돌아오자. 기능 구현은 너무 간단하다.

위 코드대로 'fail.only'일 때, Annotation과 _only 필드를 적절히 추가해준다. 추상화 끝! 😉

4. 타입 추가

타입을 추가해줄 차례이다. 이 부분에서 조금 고민이 많았다.

1. only 속성이니, only의 함수 시그니쳐를 따르자. (첫 커밋)
2. 앗. 근데 보통 우리가 only를 쓸 때 TC를 다 써두고, 특정 테스트만 확인할 때 붙이지 않나? 그럼 fail이 작성된 상태에서 fail.only로 바뀔텐데, fail의 시그니처를 따르는게 UX적으로 더 좋겠네. (두 번째 커밋)

Maintainer : 엥 이전이랑 함수 시그니처 왜 바뀌었나요? only에 없는 fail 시그니처 지우세요. Pengoose : 네! (내가 모르는 히스토리나 컨벤션이 있구나. 일단 따르자! 혹시 추후 Issue가 나오면, 그때 토의 해보는걸로!)

5. 회귀 테스트 추가

기존 only 테스트에 영향이 없는 테스트에 fail.only 테스트까지 추가해주고, (예를들어, 여러개의 only. 즉, test.describe.only, test.only에 대한 테스트)

기존 only, describe.only의 컨벤션을 따라 회귀 테스트 작성 나머지는 Reg TC는 너무 기니까 링크로!

6. PR 및 merged

> PR #33001

7. Release

> v1.49.0

GPT API나 개인 인스턴스 사용 시, 질문과 다른 언어로 답변하는 문제가 종종 발생한다. 특히 파일 검색이나 인터넷 검색을 사용할 때 빈번하게 나타난다.

프롬프트 개선으로 이를 해결하고자 하였지만, 생각보다 문제가 해결되지 않아 코드 레벨에서 이를 해결하고자 한다.

귀납적 경험

경험상, 질문의 마지막에 언어를 명시하면(예: "한국어로 답변해줘") 문제는 대부분 해결된다. 이를 자동화하기 위해 질문의 언어를 감지해 적절한 답변 요청 문구를 추가하는 방식으로 해결하고자 한다.

사용자의 질문 언어를 감지해 해당 언어로 답변을 요청하는 Suffix를 자동으로 추가하는 방식으로 언어 오류를 최소화하고자 한다.

2. 간단한 해결책

구현은 너무나 간단하다. 브루트포스로 문자열을 순회하며 regex(또는 아스키 코드)로 언어의 특성을 파악하여 해시맵에 가중치를 기록하는 선형적으로 증가하는 O(n) 방식이다.

type Language = 'en' | 'ko' | 'ja';

export const Prompt = {
  getLanguage(message: string): Language {
    const weight: Record<Language, number> = {
      en: 0,
      ko: 0,
      ja: 0,
    };

    for (const char of message) {
      if (/[a-zA-Z]/.test(char)) {
        weight.en++;
      } else if (/[ㄱ-ㅎ|ㅏ-ㅣ|가-힣]/.test(char)) {
        weight.ko++;
      } else if (/[\u3040-\u30ff\u4e00-\u9faf]/.test(char)) {
        weight.ja++;
      }
    }

    const detectedLanguage = (Object.keys(weight) as Language[]).reduce(
      (maxLang, lang) => (weight[lang] > weight[maxLang] ? lang : maxLang),
      'en' as Language
    );

    return detectedLanguage;
  },

  addSuffix(message: string) {
    const languageSuffixMap = {
      ko: '한국어로 답변해주세요.',
      en: 'Please answer in English.',
      ja: '日本語で回答してください.',
    };

    const languageKey = Prompt.getLanguage(message);

    return `${message} ${languageSuffixMap[languageKey]}`;
  },
};

3. 통계적 표본 검출을 통한 최적화

평균적으로 들어오는 메시지는 100~150자 사이로, 띄어쓰기를 제외(한국 사용자 기준) 모든 문자를 검사하는 대신, 메시지의 일부만 샘플링해도 충분히 정확한 언어 감지가 가능하다. 이를 통해 성능을 개선하고자 한다.

메시지 길이에 간격 샘플링을 진행하여 k번째 문자마다 샘플링하여 성능과 정확성의 균형을 맞춰 시간복잡도를 O(n)에서 O(n/k). 로 변경하고자 한다.

// k번째 문자만 검토하도록 수정
for (let i = 0; i < message.length; i += k) {
  const char = message[i];
  if (/[a-zA-Z]/.test(char)) {
    weight.en++;
  } else if (/[ㄱ-ㅎ|ㅏ-ㅣ|가-힣]/.test(char)) {
    weight.ko++;
  } else if (/[\u3040-\u30ff\u4e00-\u9faf]/.test(char)) {
    weight.ja++;
  }
}

가설 검증

적절한 k ?

띄어쓰기로 나눠지는 단위를 청크라고 가정하자.(일어는 띄어쓰기가 없으니 제외한다.)

한국어:

한국어는 보통 조사와 어미가 하나의 단어에 추가로 결합된다. 하나의 청크에는 본래의 단어(24자가 7080%를 차지한다)와 조사나 어미(12자)가 결합되어, 평균적으로 한 청크는 35자 정도일 것으로 예상하였다.

영어:

영어는 조사나 어미 대신 전치사나 대명사 같은 별도의 단어들이 따로 표기된다. 즉, 하나의 청크는 기본적으로 단어 자체만으로 구성된다. 단어의 평균 길이가 약 4.75.4자이므로, 하나의 청크는 보통 45자로 구성된다.

일본어:

일본어는 조사나 접속사 같은 요소들이 단어에 결합되지 않고 독립적으로 쓰이는 경우가 대부분으로 보인다. 다만, 문법상의 특성(동사 변화나 조사의 영향)으로 청크가 길어질 수 있다. 하나의 단어(한자 포함)는 평균 45자 정도이며, 여기에 조사나 어미가 추가되어, 하나의 청크는 68자 정도로 추산한다.

> ref : 한국어 형태소 분석기 HAM의 형태소 분석 및 철자 검사 기능

> ref : Linguisticscentral

> ref : inter-contact

4. 통계적 표본 검출을 통한 적절한 k 값 산출

모집단에서 적절한 표본 크기를 구하기 위해 통계학에서는 신뢰도와 오차범위를 고려한 표본 추출 방식을 사용한다.

실데이터(평균 메시지 길이)의 크기를 기반으로 적절한 k 값을 구하기 위해 신뢰 구간을 적용한다.

신뢰도 도출 및 Trade-off 의사결정

n = (Z^2 * p * (1-p)) / e^2
// n: 신뢰 임계치를 넘기기 위해, 최소로 샘플링 해야하는 표본 문자열의 크기
// Z: 신뢰도에 따른 Z값 (99% 신뢰도에서 Z = 2.576)
// p: 모집단의 비율 (언어가 잘못 분류될 확률을 50%로 가정. 보수적 계산)
// e: 허용 오차 (일반적으로 5%)

이를 통해 필요한 표본 크기를 계산하자. 한국 사용자 기준으로 평균적인 질문 메시지의 길이는 100자에서 200자 사이였다. 여기서는 높은 신뢰도를 위해 모집단의 평균을 100자로 계산한다.

99% 신뢰도를 넘기기 위해 필요한 표본 크기(n)는 약 87(87%)자를 샘플링해야 충분히 높은 신뢰도로 언어를 감지할 수 있음을 의미한다.

k 값은 약 1.15로 이는 사실상 거의 모든 문자마다 샘플링하는 방식에 가깝다. 개선되는 시간복잡도는 굉장히 미미하지만, 언어가 잘못 매핑되어 UX를 해치는 기대값을 생각했을 때, 득보다는 실이 크다고 판단되었다.

5. 결론

문자열이 굉장히 긴 경우, 위에서 언급한대로 표본 추출을 통해 시간복잡도를 개선하거나, 나아가 사용하는 언어별 아스키코드를 360도로 분배하여 원점으로부터 기울기 및 좌표를 계산하는 방식으로 최적화가 가능해보인다. 시간복잡도 개선을 위한 다양한 아이디어 적용이 가능해보인다.

shadcn-chat에서 제공하는 ChatInput 컴포넌트는 TextArea를 한 단계 더 추상화한 고차 컴포넌트이다. textArea에서 composition-based language를 submit할 경우, 마지막 단어가 중복되어 전달되는 이슈가 존재한다. onComposition (**react) 메서드로 제어하고자 하였으나 interface에서 이를 제공하지 않아 에러가 발생하였다. (기능적으로는 동작. 따라서 type선언 문제)

2. 원인 파악

원인은 interface 상속에 있었다. 하나의 컴포넌트를 다시 추상화하는 과정에서, 의도적으로 기능을 제한하는 경우가 아니라면 기존에 사용하던 interface를 적절히 잘 상속해주는 것이 중요하다.

Prev

import { Textarea } from "@/components/ui/textarea";
import { cn } from "@/lib/utils";

// ⛳️ TextArea를 상속하여 그대로 spread하는 것이 아닌 직접 추상화하여 상속
interface ChatInputProps {
  className?: string;
  value?: string;
  onKeyDown?: (event: React.KeyboardEvent<HTMLTextAreaElement>) => void;
  onChange?: (event: React.ChangeEvent<HTMLTextAreaElement>) => void;
  placeholder?: string;
}

const ChatInput = React.forwardRef<HTMLTextAreaElement, ChatInputProps>(
  ({ className, value, onKeyDown, onChange, placeholder, ...props }, ref) => (
    <Textarea
      autoComplete="off"
      value={value}
      ref={ref}
      onKeyDown={onKeyDown}
      onChange={onChange}
      name="message"
      placeholder={placeholder}
      className={cn(
        "max-h-12 px-4 py-3 bg-background text-sm placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-ring disabled:cursor-not-allowed disabled:opacity-50 w-full rounded-md flex items-center h-16 resize-none",
        className,
      )}
      {...props}
    />
  ),
);
ChatInput.displayName = "ChatInput";
export { ChatInput };

물론, 해당 모듈은 기존의 모듈을 다시 추상화한 컴포넌트이기 때문에, 기존 shadcn의 Textarea 컴포넌트 의존성으로 이런 추상화가 발생한 것이 아닌지 히스토리를 체크해야한다.

Textarea(shadcn)

import * as React from "react"

import { cn } from "@/lib/utils"

export interface TextareaProps
  extends React.TextareaHTMLAttributes<HTMLTextAreaElement> {}

const Textarea = React.forwardRef<HTMLTextAreaElement, TextareaProps>(
  ({ className, ...props }, ref) => {
    return (
      <textarea
        className={cn(
          "flex min-h-[60px] w-full rounded-md border border-input bg-transparent px-3 py-2 text-sm shadow-sm placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring disabled:cursor-not-allowed disabled:opacity-50",
          className
        )}
        ref={ref}
        {...props}
      />
    )
  }
)
Textarea.displayName = "Textarea"

export { Textarea }

그런거 없었다. 그저 실수였다는 것을 확인하였으니 상속되는 interface를 정정해주자. 두 가지 선택지가 있다.

1. HTMLTextAreaElement 상속하기

2. 의존성 모듈을 사용하니 shadcn에서 사용한 Textarea 그대로 상속하기.

   물론, 2가 더 바람직하겠지만, 기존 모듈에서 추상화 해둔 방식을 살펴보니, shadcn에서 추상화 해둔 interface가 아닌 전부 직접 추상화 하여 상속하는 방식을 채택했다. 이럴 경우, shadcn에서 제공하는 interface가 HTML API가 아닌 자체 선언방식으로 변경되면 해당 모듈 또한 재작업을 진행해야 한다는 문제점이 발생하지만, HeadlessUI(shadcn) 특성상 HTML API를 벗어날 가능성이 낮다고 판단하여 기존 컨벤션(HTMLTextAreaElement 상속하기)을 따르기로 하였다.

3. 해결

interface를 올바르게 상속하고, 불필요한 매개변수를 제거하는 간단한 작업 후, PR하였다.

4. PR 및 merged

> PR #1410

maintainer가 한 분이시고, contribution에 대한 문서 작성이 TODO에 담겨있던 초기 프로젝트라 LinkedIn 프로필로 gentle ping을 PR 컨텍스트를 한 번 날리게 되었다.

Merge 후 서윗하게 DM까지 보내주셨다. Maintainer의 gentle함이 오픈소스에 주는 영향을 크게 느끼게 되었다. 한동안 멈췄던 오픈소스를 다시 잡아볼까 한다.

PS 근황

목표였던 D5를 달성하였다.

취업 후 한동안 PS와 CP를 손에서 놓았지만, 부트캠프의 알고리즘 멘토 제안과 준아님이 추천해준 백준방에서 자극을 받아 다시 PS를 잡게 되었다.

어디서 왔는가?

나의 PS는 어떻게 시작됐을까? > 1년 전 PS 이야기(G3 달성)

비단 PS 뿐 아니라, 삶에서 운이라는 요소는 꽤 크게 작용한다.

1. 23년 5월 면접에서 면접관님의 알고리즘, 자료구조 중요성 강조
2. 디스코드 작업방에서 백준 풀던 걸 준아님이 발견. 알고리즘 가이드 + CP(앳코더) 추천 해주심.
3. 성장(G5 => G4 => ... G1)
4. 앳코더 참여 + 백준 P5 달성
5. 취업 및 휴식기
6. 부트캠프 알고리즘 멘토 + 백준방 참여 => CP, 알고리즘 다시 시작

내 PS. 나아가 개발자의 삶에서의 운. 즉, 내가 멈추지 않고 나아갈 수 있도록 돕는 스승이자 친구이자 환경. 나아가 방향성과 통찰력. 그리고 가능성을 제공해준 사람은 준아님이었다.

마침 저번 휴일에 준아님과 오랜만에 (거의 반년..?) 식사를 했다. 노래방 3시간 야무지게 땡겼는데, 나에게는 항상 감사한 스승이자 친구다. 고마운 사람들에게 더 나은 영향력을 끼칠 수 있도록, 함께 정진해야겠다.

준아님 항상 감쟈(potato 아님)합니다.

어디로 갈 것인가?

• 목표를 달성했으니 새로운 알고리즘 학습은 한 동안 삼가야겠다.
• 다만, 배운걸 기반으로 CP는 꾸준히 참여할 것 같다.
• 준아님이 추천해주신 Serverless와 AWS 강의실 톡방에서 활동 및 학습
• 위의 것들이 끝난다면 서비스 런칭

감사합니다.

항상 주변 사람들에게 감사할 따름이다.

• PS, 인프라에 대해 알려주시고 모각코, 노래방 야물딱지게 즐겨주시는 준아님

• 힘들었던 시기부터 항상 응원해주고 따듯하게 곁을 지켜준 동하형
• 오픈소스 알려주신 영준님
• 한 번씩 안부 전해주시는 강준님
• 오픈소스 자극 받게 해주시는 종훈님, 인제님.
• 그리고 항상 같이 작업하는 작업방 분들.

감사합니다.

> Issue #1267 createTheme에 themeContract를 넣어주면 보통 자동완성(타입 추론)이 지원되어야하는데, 그렇지 않아 불편함이 많았다.

2. 원인 파악

원인은 함수 오버로딩 순서에 있었다. TS 컴파일러는 가장 먼저 매칭(상단)되는 시그니처를 찾아 그 시그니처에 맞는 타입을 함수의 타입으로 해석한다.

export function createTheme<ThemeTokens extends Tokens>(
  tokens: ThemeTokens, // ⛳
  debugId?: string,
): [className: string, vars: ThemeVars<ThemeTokens>];
export function createTheme<ThemeContract extends Contract>(
  themeContract: ThemeContract, // ⛳
  tokens: MapLeafNodes<ThemeContract, string>,
  debugId?: string,
): string;
export function createTheme(arg1: any, arg2?: any, arg3?: string): any {
  const themeClassName = generateIdentifier(
    typeof arg2 === 'object' ? arg3 : arg2,

보통 유저가 빈번하게 사용하는 함수 시그니처는 두 번째 시그니처이다. createTheme의 첫 매개변수로 객체를 넘겨주는 과정에서 첫 번째 함수 시그니쳐가 매핑되었고, themeContract를 넘겨준 상태에서 두 번째 매개변수가 적절한 타입 추론을 제공하지 못하였다.

3. 해결

함수 오버로딩 순서를 변경해주는 것으로 문제를 해결했다. 다만, 이에 대한 사이드 이펙트도 고려해야한다. 두 번째 함수 시그니처를 첫 번째로 옮기더라도 변경된 함수 시그니처(기존의 첫 번째 시그니처)의 두 번째 매개변수는 optional한 string값이기 때문에 해당 함수 시그니처를 사용하는 상황에서도 사이드 이펙트가 크지 않을 것이라 판단하였다.

export function createTheme<ThemeContract extends Contract>(
  themeContract: ThemeContract, // ⛳
  tokens: MapLeafNodes<ThemeContract, string>,
  debugId?: string,
): string;
export function createTheme<ThemeTokens extends Tokens>(
  tokens: ThemeTokens,
  debugId?: string,
): [className: string, vars: ThemeVars<ThemeTokens>];
export function createTheme(arg1: any, arg2?: any, arg3?: string): any {
  const themeClassName = generateIdentifier(
    typeof arg2 === 'object' ? arg3 : arg2,

해당 부분은 maintainer의 판단에 맡기기로 하였고, 사이드 이펙트(tradeOff)가 존재한다면 실제 사용자의 사용 빈도에 따라 함수 시그니처의 순서를 정렬하는 것이 맞아보였다.

함수 시그니처 추론에 대한 사이드 이펙트가 없다고 판단하셨는지, 사용빈도는 크게 상관이 없을 것 같다고 피드백을 주셨다. 바로 merge.

4. PR 및 merged

> PR #1410 Closed된 PR들을 살펴보면 vanilla-extract는 외부 기여를 많이 받지 않는 것 같았다.

거의 1달 전에 날렸던 PR이라 잊고 있었는데 어떻게 잘 merge되었다. 😉👍

5. Release

> @vanilla-extract/css@1.15.3

> Issue #5716

concurrent 설정을 한 하위 depth의 test suite에 sequantial 설정을 오버라이딩하면 적용이 되지않는 문제가 존재한다.

2. 원인 파악

function createSuite() {
  function suiteFn(this: Record<string, boolean | undefined>, name: string | Function, factoryOrOptions?: SuiteFactory | TestOptions, optionsOrFactory: number | TestOptions | SuiteFactory = {}) {
    const mode: RunMode = this.only ? 'only' : this.skip ? 'skip' : this.todo ? 'todo' : 'run'
    const currentSuite = getCurrentSuite()
    let { options, handler: factory } = parseArguments(
      factoryOrOptions,
      optionsOrFactory,
    )
    // inherit options from current suite
    if (currentSuite?.options)
      options = { ...currentSuite.options, ...options }

    // ⛳️ 이곳이 문제다.
    options.concurrent = this.concurrent || (!this.sequential && options?.concurrent)
    options.sequential = this.sequential || (!this.concurrent && options?.sequential)

    return createSuiteCollector(formatName(name), factory, mode, this.shuffle, this.each, options)
  }

명시적으로 값을 할당하지 않을 때, undefined인 경우를 고려해야해서 복잡도가 빠르게 올라간 코드의 사례라고 생각된다. 해당 코드는 다른 코드에서 의존성이 굉장히 높았으며, this와 config를 동시에 사용하고 있어 경우의 수가 굉장히 많아 버그가 발생한 사례이다.(의존성이 있는 다른 함수에서도 비슷하게 undefined 및 this와 매개변수의 혼용 사용으로 인한 복잡도--부채--가 많이 쌓여있는 상태였다.)

전역으로 코드를 변경하려다, 해당 부분만 수정하면 잦게 변경사항이 발생할 부분이 아니라고 판단해서 변경을 최소화하고 변수 선언을 통해 가독성을 확보하는 쪽으로 결정하였다.

3. 해결

1. 기존에 통과하지 못하는 회귀 테스트의 주석을 풀어주고,

2. 기존 상속 로직을 아래와 같이 변경.

    // inherit concurrent / sequential from suite
    const isConcurrent = options.concurrent || (this.concurrent && !this.sequential)
    const isSequential = options.sequential || (this.sequential && !this.concurrent)
    options.concurrent = isConcurrent && !isSequential
    options.sequential = isSequential && !isConcurrent

3. 회귀 테스트 통과 확인

4. PR 및 merged

> PR(merged)

샤라메트 형님과 인제님의 따봉도치 👍

Vitest v2.0.0-beta.5 배포

https://github.com/vitest-dev/vitest/releases/tag/v2.0.0-beta.5

Vitest v2 배포

https://github.com/vitest-dev/vitest/releases/tag/v2.0.0

1. 문제 상황

각각 [-0], [-NaN]가 주어졌을 때, 예상과 다르게 포매팅이 진행된다는 것이다.

예상

 ✓ test/basic.test.ts (2)
   ✓ -0 // ⛳
   ✓ -NaN // ⛳

실제 결과

 ✓ test/basic.test.ts (2)
   ✓ 0 // ⛳
   ✓ NaN // ⛳

2. 원인 파악

다음은 vitest에 추상화되어있는 test suite의 description(describe, test, it)의 문자열 포매팅 함수(format)의 일부이다.

case '%f': return Number.parseFloat(String(args[i++])).toString()

위 코드는 아래의 경우를 제대로 처리하지 못한다.

String(-0)
// '0'

String(-NaN)
// 'NaN'

3. 트러블슈팅(-NaN)

분기처리를 통해 edgeCase를 처리하였다. 이 과정에서 -0을 처리하는 것은 문제가 없었지만 -NaN을 처리하는 것은 조금 난이도가 있었다. 이유는 아래와 같다.

NaN;
// > NaN

-NaN;
// > NaN // ⛳ -NaN은 초기화 시점에서 -NaN이 아니라 NaN으로 평가된다.

NaN === NaN;
// false

Object.is(NaN, -NaN); // ⛳
// true

JS가 -NaN을 추상화 하는 과정에서 위 사이드 이펙트를 고려하지 못한 것 같았다. 따라서, 정상적인 negative 값인지 판단하는 것이 불가능하다.

String(-NaN);
// 'NaN'

4. 해결 아이디어 발견: (sign bit와 IEEE 표준)

검색하며 문제 해결에 대한 아이디어를 찾아보았다. IEEE와 관련된 웹사이트를 돌아다니다 NaN에 대한 규약에서 아이디어를 얻었고, JS에서 sign bit에 접근하여 이에 대한 값(부호)를 확인할 수 있다면 해결할 수 있는 문제였다.

> IEEE > FLODOC

5. 해결

값을 64비트 부동 소수점 배열로 변경한 뒤, 값 할당 이후 buffer값을 32비트 정수 배열로 바꿔 signIndex(최상위 인덱스. 즉, 부호)에 접근하여 1(음수)인지 확인하면 -NaN의 부호를 확인할 수 있는지 확인할 수 있었다.

/**
 * Checks if a given number is NaN and if it is a negative NaN.
 *
 * @param {number} val - The number to check.
 * @returns {boolean} - True if the number is a negative NaN, false otherwise.
 */
export function isNegativeNaN(val: number): boolean {
  // NaN이 아니면 ealry return.
  if (!Number.isNaN(val)) return false;

  // 64비트배열 생성
  const f64 = new Float64Array(1);
  // Float64Array [0, buffer: ArrayBuffer(8), byteLength: 8, byteOffset: 0, length: 1, Symbol(Symbol.toStringTag): 'Float64Array']

  // 값 할당
  f64[0] = val;
  // Float64Array [NaN, buffer: ArrayBuffer(8), byteLength: 8, byteOffset: 0, length: 1, Symbol(Symbol.toStringTag): 'Float64Array']

  // buffer값으로 32비트 정수 배열 생성
  const u32 = new Uint32Array(f64.buffer);
  // Uint32Array(2) [0, 4294443008, buffer: ArrayBuffer(8), byteLength: 8, byteOffset: 0, length: 2, Symbol(Symbol.toStringTag): 'Uint32Array']

  // 상위 32비트(index 1)의 마지막 비트가 음수(1)인지 확인
  const isNegative = u32[1] >>> 31 === 1;

  return isNegative;
}

잘 작동한다. 👍

isNegativeNaN(-NaN);
// true

isNegativeNaN(NaN);
// false

isNegativeNaN(-0);
// false

// ...

6. PR 및 모듈 배포

애초에 -NaN을 쓴다는 것 자체가 잘못된 개념이긴 하지만, 이에 관한 엣지케이스가 대부분의 라이브러리에 되어있지 않다는 것을 확인하였다. 조만간 vitest 말고도 다른 오픈소스에 작업을 진행할 예정이다.

PR 후, 다른사람들 편하게 쓰라고 배포까지 완료하였다.

> PR

> npm

7. Maintainer님의 빠꾸

PR(Closed)

sheremet 형님 : 거기 바꾸면 breakChange 되니까 다른 방식으로 해결하세요. 저도 고민중임.

잠시 슬픔과 죄송함의 복합적인 감정을 음미하였다. 뭔가 내 부족한 지식으로 메인테이너 형님의 시간을 빼았아, 폐가 되었기 때문이었을까. 이번 피드백으로 또 새로운 것을 배웠지만, 그래도 죄송한 마음은 어쩔 수 없을 따름이다.

8. 새 PR

format 자체에서 판단하는 것이 아닌, runner의 formatTitle에서 정규표현식으로 %f를 추출하는 과정에서 해당 값이 -0이나 -NaN일 경우 %f를 -%f로 바꾸는 것. 이 방식이 모든 코드를 살펴보았을 때, 셰르멧 형님이 원하는대로 변경점은 최소화가 된다.

금요일 퇴근 후, 시간이 조금 있어 자기 전 PR을 완성하였다.

9. Merge

1. 기존 formatTitle에 대한 테스트가 존재하지 않았고
2. 해당 함수는 외부로 export되지 않으며
3. format이 완성된 title을 suite 함수 내부에서 this로 접근하는 것이 불가능했다.

그렇기에 회귀 테스트를 작성할 수 없어서, 방향성에 대한 피드백을 구했지만 스크린샷으로 올렸던 자체 테스트 + sheremet 형님이 직접 테스트로 확인하셨는지 그냥 merge 때리셨다.

> PR(merged)

Release : Vitest v.2.0.0-beta.7

import { useSyncExternalStore } from 'react';

const externalState = { value: 42 };
const listeners = new Set();

const getSnapshot = () => {
  return externalState.value;
};

const subscribe = (listener: () => void) => {
  listeners.add(listener);
  return () => {
    listeners.delete(listener);
  };
};

const Component = () => {
  const state = useSyncExternalStore(subscribe, getSnapshot);
  return <div>Current value: {state}</div>;
}

하지만, 위 방식에서 객체 내부에서 복잡한 비즈니스 로직을 추상화 하는 경우. 하나의 문제점이 발생한다.

state가 너무 많은 프로퍼티들을 가질 수 있다.

React에서 제공하는 useSyncExternalStore가 state 자체를 구독하는 방식은 굉장히 직관적이다. 하지만 사용하고자 하는 모든 값을 모두 state로 추상화해야 한다는 문제가 있다. 예를들어, 현재 유저가 재생중인 음악을 알고자한다면 playlist와 index 두 개의 state로 원하는 값을 얻을 수 있지만, useExternalStore의 경우 state에 currentMusic이라는 필드를 추상화해야 한다.

해결책1 (추상화 된 값 반환)

이러한 문제는 getSnapshot 콜백함수가 state 그 자체를 반환하는 것이 아닌 추상화 된 상태를 반환하는 방식으로 해결할 수 있다.

// 이해를 돕기 위한 의사 코드
const playerState = {
    playlist: Music[];
    index: number;
}

export abstract class StateManager<T> {
  constructor(protected state: T) {}

  public selectors = {
    playlist: this.state.playlist,
    currentMusic: this.state.playlist[this.state.index],
  };

  // ... codes
  public getSnapshot() {
    return this.selectors; // ⛳️ this.state가 아닌 추상화된 selectors 반환
  }
}

문제점 1: 고정된 메모리 주소

하지만 해결책 1의 방식은 useSyncExternalStore의 re-rendering 알고리즘에 동기화되지 못한다. 내부 state가 변경되어도 selectors의 힙 메모리 주소 자체는 변경되지 않기 때문이다.

해결책 2: 변경된 메모리 주소 반환

selectors의 값들이 state를 그대로 구독하는 것이 아니라 호출 시점에서 변경된 state를 반환하도록 한다.

class Playlist extends StateManager<PlaylistStatus> {
  selectors = {
    playlist: () => this.state.playlist,
    currentMusic: () => this.state.playlist[this.state.index],
  };

문제점 2: re-render 알고리즘과 동기화되지 않음

하지만 여전히 getSnapshot의 코드를 변경하지 않는다면 문제점1에서 다룬 본질적인 문제는 해결되지 않는다. selectors 프로퍼티들의 함수 자체의 메모리 주소는 변경되지 않기 때문이다.

이쯤에서 추상화된 코드에 대해 살펴보자.

언제 re-render(forceUpdate)되는가?

아래는 useSyncExternalStore의 구현체이다. re-render의 로직은 react-hook-form의 비제어 컴포넌트를 제어 컴포넌트로 동기화하는 로직과 비슷하다.

export function useSyncExternalStore<T>(
  subscribe: (() => void) => () => void,
  getSnapshot: () => T,
  getServerSnapshot?: () => T,
): T {
  // ...codes
  const value = getSnapshot();
  const [{inst}, forceUpdate] = useState({inst: {value, getSnapshot}}); // ⛳️

  // ⛳️
  useLayoutEffect(() => {
    inst.value = value;
    inst.getSnapshot = getSnapshot;
    if (checkIfSnapshotChanged(inst)) {
      forceUpdate({inst});
    }
  }, [subscribe, value, getSnapshot]);

  // ⛳️
  useEffect(() => {
    // Check for changes right before subscribing. Subsequent changes will be
    if (checkIfSnapshotChanged(inst)) {
      // Force a re-render.
      forceUpdate({inst}); 
    }

    const handleStoreChange = () => {
      if (checkIfSnapshotChanged(inst)) {
        // Force a re-render.
        forceUpdate({inst});
      }
    };
    return subscribe(handleStoreChange);
  }, [subscribe]);

  useDebugValue(value);
  return value;
}

function checkIfSnapshotChanged<T>(inst: {
  value: T,
  getSnapshot: () => T,
}): boolean {
  const latestGetSnapshot = inst.getSnapshot;
  const prevValue = inst.value; // ⛳️
  try {
    const nextValue = latestGetSnapshot(); // ⛳️
    return !is(prevValue, nextValue); // ⛳️
  } catch (error) {
    return true;
  }
}

function is(x: any, y: any) {
  return (
    (x === y && (x !== 0 || 1 / x === 1 / y)) || (x !== x && y !== y) 
  );
}

const objectIs: (x: any, y: any) => boolean =
  typeof Object.is === 'function' ? Object.is : is;  // ⛳️

export default objectIs;

useSyncExternalStore의 diff 알고리즘은 하나의 state를 구독하도록 추상화 되어있다. 따라서 Object.is(objetIs)를 사용하여 re-rendering의 여부를 결정하며, 해당 알고리즘을 재사용하기는 어렵다. 필자가 추상화 한 selector의 값들은 함수가 반환하는 객체이기 때문에 메모리 주소가 계속 변경되기 때문이다.

해결책 2: deepEqual

따라서, getSnapshot 내부에서 deepEqual을 추상화하여 실질적인 값의 변화가 발생한 경우, 조건부로 값을 반환해야 한다.

• 휴리스틱 알고리즘을 학습하던 도중, state의 depth가 보통 크기 않기 때문에 득보단 실이 많다고 판단하여 간단하게 추상화한 뒤, 계속해서 발전시키기로 했다.

deepEqual

const deepEqual = (obj1: any, obj2: any, cache = new WeakMap()): boolean => {
  const isSameValue = obj1 === obj2;
  if (isSameValue) {
    return true;
  }

  const isSameType = typeof obj1 === typeof obj2;
  if (!isSameType) {
    return false;
  }

  const isEitherNull = obj1 === null || obj2 === null;
  if (isEitherNull) {
    return false;
  }

  const isEitherObject = typeof obj1 === 'object' && typeof obj2 === 'object';
  if (!isEitherObject) {
    return false;
  }

  const isCircularReference = cache.has(obj1) && cache.get(obj1) === obj2;
  if (isCircularReference) {
    return true;
  }

  const obj1Keys = Object.keys(obj1);
  const obj2Keys = Object.keys(obj2);

  const isSameLength = obj1Keys.length === obj2Keys.length;
  if (!isSameLength) {
    return false;
  }

  const obj2KeysSet = new Set(obj2Keys);
  cache.set(obj1, obj2);

  for (const key of obj1Keys) {
    if (!obj2KeysSet.has(key) || !deepEqual(obj1[key], obj2[key], cache)) {
      return false;
    }
  }

  return true;
};

적용

stateManager

import { deepEqual } from '@/utils/deepEqual';

export abstract class StateManager<T> {
  public listeners: Set<() => void> = new Set();

  private lastSnapshot: any = null;

  constructor(protected state: T) {}

  protected computeSnapshot(): StateManager<T>['selectors'] {
    const selectors = Object.fromEntries(
      Object.entries(this.selectors).map(([key, selectorFn]) => {
        const getSelector = selectorFn as () => any;
        const selector = getSelector();

        return [key, selector];
      })
    ) as StateManager<T>['selectors'];

    return selectors;
  }

  public getSnapshot(): StateManager<T>['selectors'] {
    const currentSnapshot = this.computeSnapshot();

    const isInitial = this.lastSnapshot === null;
    const isChanged = !deepEqual(this.lastSnapshot, currentSnapshot);

    if (isInitial || isChanged) this.lastSnapshot = currentSnapshot;

    return this.lastSnapshot;
  }

  public set(newState: Partial<T>) {
    this.state = { ...this.state, ...newState };
    this.listeners.forEach((listener) => listener());
  }

  public subscribe(listener: () => void): () => void {
    this.listeners.add(listener);
    return () => this.listeners.delete(listener);
  }

  abstract selectors: {
    [K in keyof Partial<T>]: any;
  };

  abstract actions: {
    [key: string]: (payload: any) => void;
  };
}

useManager

import { useSyncExternalStore } from 'react';
import { StateManager } from './stateManager';

export const useManager = <T extends StateManager<any>>(manager: T) => {
  const selectors = useSyncExternalStore(
    manager.subscribe.bind(manager),
    manager.getSnapshot.bind(manager)
  ) as {
    [K in keyof T['selectors']]: ReturnType<T['selectors'][K]>;
  };

  const actions = manager.actions as {
    [K in keyof T['actions']]: T['actions'][K];
  };

  return { selectors, actions };
};

적용 예시(Playlist)

import { PlaylistStatus } from '@/types/playlist';
import { StateManager } from './stateManager';
import { Music, PlaylistProps } from '@/types';

class Playlist extends StateManager<PlaylistStatus> {
  selectors = {
    playlist: () => this.state.playlist,
    currentMusic: () => this.state.playlist[this.state.index],
  };

  actions = {
    play: (index: number) => {
      this.set({ index });
    },

    next: () => {
      const { playlist, index } = this.state;
      this.set({ index: this.getIncresedIndex({ index, playlist }) });
    },

    prev: () => {
      const { playlist, index } = this.state;
      this.set({ index: this.getDecresedIndex({ index, playlist }) });
    },

    add: (music: Music) => {
      const { playlist } = this.state;

      if (playlist.some(({ id }) => id === music.id)) return;

      this.set({ playlist: [...playlist, music] });
    },

    remove: (music: Music) => {
      const { playlist, index } = this.state;
      const targetIndex = playlist.findIndex((item) => item.id === music.id);
      const isTargetAfterCurrent = targetIndex > index;

      const newPlaylist = playlist.filter((item) => item.id !== music.id);
      const newIndex = isTargetAfterCurrent
        ? index
        : this.getDecresedIndex({ index, playlist });

      this.set({
        playlist: newPlaylist,
        index: newIndex,
      });
    },
  };

  private isEmpty(playlist: Music[]) {
    return playlist.length === 0;
  }

  private isFirstMusic(index: number) {
    return index === 0;
  }

  private isLastMusic({ index, playlist }: PlaylistProps) {
    return index === playlist.length - 1;
  }

  private getIncresedIndex({ index, playlist }: PlaylistProps) {
    const isLastMusic = this.isLastMusic({ index, playlist });
    if (isLastMusic) return 0;

    return index + 1;
  }

  private getDecresedIndex({ index, playlist }: PlaylistProps) {
    const isEmpty = this.isEmpty(playlist);
    if (isEmpty) return 0;

    const isFirstMusic = this.isFirstMusic(index);
    if (isFirstMusic) return playlist.length - 1;

    return index - 1;
  }
}

const initialState: PlaylistStatus = {
  playlist: [],
  index: 0,
};

export const playlistManager = new Playlist(initialState);

jotai에서 사용했던 도메인 별로 상태를 작게 쪼개, DI를 사용하는 방식도 추후에 구현해볼 예정이다.

1. 하나의 View Model은 AtomManager라는 추상클래스을 상속받는다.

이는 상태관리 컨벤션을 확립하기 위함이다. 구현체는 아래와 같다.

import { Atom, WritableAtom, atom } from 'jotai';

export abstract class AtomManager<T> {
  public initialState: T;
  protected atom: WritableAtom<T, any, void>;

  constructor(initialState: T) {
    this.initialState = initialState;
    this.atom = atom(this.initialState);
  }

  abstract selectors: {
    [K in keyof Partial<T>]: Atom<T[K]>;
  };

  abstract actions: {
    [key: string]: WritableAtom<T | null, any, void>;
  };
}

각 selectors는 getter atom을 프로퍼티로 갖는다. 각 actions는 setter atom을 프로퍼티로 갖는다.

예시

class CartManager extends AtomManager<Cart> {
  constructor(initialState: Cart) {
    super(initialState);
  }

  /* Selectors */
  public selectors = {
    items: atom((get) => get(this.atom).items),
  };

  /* Actions */
  public actions = {
    add: atom(
      null,
      (get, set, { amount, product }: { amount: number; product: Product }) => {
        const { items } = get(this.atom);
        // ...codes
      }
    ),

    delete: atom(null, (get, set, product: Product) => {
      const { items } = get(this.atom);
      // ...codes
    }),
  };
}

const initialData: Cart = {
  items: [],
};

export const cartManager = new CartManager(initialData);

2. 고차함수를 이용해 Atom을 hook으로 래핑하고 타입을 동적으로 추론한다.

useManager은 두 가지 역할을 수행해야한다.

1. 추상클래스로 추상화한 field(selectors, actions)가 가진 method Type들을 동적으로 추론해 반환해야한다.
2. atom을 useAtomValue 등의 훅을 사용하여 state로 변환해야 한다.

export const useManager = <T extends AtomManager<any>>(manager: T) => {
  const selectors = Object.fromEntries(
    Object.entries(manager.selectors).map(([key, atom]) => [
      key,
      useAtomValue(atom),
    ])
  ) as {
    [P in keyof T['selectors']]: T['selectors'][P] extends Atom<infer V>
      ? V
      : never;
  };

  const actions = Object.fromEntries(
    Object.entries(manager.actions).map(([key, actionAtom]) => [
      key,
      useSetAtom(actionAtom),
    ])
  ) as {
    [P in keyof T['actions']]: T['actions'][P] extends WritableAtom<
      any,
      infer U,
      void
    >
      ? (param: U[0]) => void
      : never;
  };

  return { selectors, actions };
};

문제점 발생 - Callback 함수 내부에서 커스텀훅 호출

현재 코드는 콜백함수 내부에서 커스텀훅을 호출하여, hook의 호출 순서를 보장받지 못한다.

export const useManager = <T extends AtomManager<any>>(manager: T) => {
  const selectors = Object.fromEntries(
    Object.entries(manager.selectors).map(([key, atom]) => [
      key,
      useAtomValue(atom), // 🚩 Error : Callback 내부에서 커스텀훅 호출
    ])
  ) as {
    [P in keyof T['selectors']]: T['selectors'][P] extends Atom<infer V>
      ? V
      : never;
  };

  const actions = Object.fromEntries(
    Object.entries(manager.actions).map(([key, actionAtom]) => [
      key,
      useSetAtom(actionAtom), // 🚩 Error : Callback 내부에서 커스텀훅 호출
    ])
  ) as {
    [P in keyof T['actions']]: T['actions'][P] extends WritableAtom<
      any,
      infer U,
      void
    >
      ? (param: U[0]) => void
      : never;
  };

  return { selectors, actions };
};

커스텀훅은 최상위 Layer에서만 호출되어야한다. Proxy를 써서 파훼를 시도했지만 역시 실패하였다.

해결 : 또 다시 고차함수(커링)

고차함수는 답을 알고있다. 커링을 응용해 props를 전달하는 함수를 반환하는 고차함수를 작성해주자. 최상위 layer에서 Hook을 사용할 수 있도록 함수로 래핑하여 반환해주자.

import { Atom, WritableAtom, useAtomValue, useSetAtom } from 'jotai';
import { AtomManager } from '@/Model/manager/atomManager';

const createUseSelector = <T>(atom: Atom<T>) => {
  return () => useAtomValue(atom); // ✅
};

const createUseAction = (atom: WritableAtom<any, any, void>) => {
  return () => useSetAtom(atom); // ✅
};

export const useManager = <T extends AtomManager<any>>(manager: T) => {
  const selectors = Object.fromEntries(
    Object.entries(manager.selectors).map(([key, atom]) => [
      key,
      createUseSelector(atom)(), // ✅
    ])
  ) as {
    [P in keyof T['selectors']]: T['selectors'][P] extends Atom<infer V>
      ? V
      : never;
  };

  const actions = Object.fromEntries(
    Object.entries(manager.actions).map(([key, actionAtom]) => [
      key,
      createUseAction(actionAtom)(), // ✅
    ])
  ) as unknown as {
    [P in keyof T['actions']]: T['actions'][P] extends WritableAtom<
      any,
      infer U,
      void
    >
      ? (param: U[0]) => void
      : never;
  };

  return { selectors, actions };
};

개선하여 @pengoose/jotai V1.1.4 배포! 😆👍

ThxTo

• 고차함수 함수 및 고차 컴포넌트 설계에 통찰력을 주신 NextStep 그리고 소인성님 감사합니다.

이 글은 오픈소스를 처음으로 기여하는 개발자들에게 도움을 주고자, 스터디 및 오픈소스 기여 과정에서 얻은 지식들을 정리한 것이다.

아래의 Flow를 따라가며 첫 오픈소스 기여를 시도해보자 🥳

1) Issue 찾아보기

PR을 할 수 있는 Issue를 찾는 방법에는 크게 2가지가 있다.

1-1) 기존 Issue를 할당받는 방법

Issue 카테고리에서 issue를 할당받는 방식이다. 아래의 조건을 만족하는 경우 PR을 생성하기 좋은 Issue이다.

1. maintainer와 방향성의 토의가 이루어져있는 경우.
2. 문제가 발생하는 조건에 대해 상세하게 기술되어있는 경우.
3. 개선 방향성을 제시해둔 경우.
4. 히스토리 파악을 위한 커밋 및 PR을 남겨둔 경우.

1-2) 직접 Issue를 생성하는 방법

코드를 직접 훑어보며 개선점을 직접 제시하는 것도 좋다.

> Issue #699

커스텀 에러에서 name field를 사용하지 않아, 이에 대한 개선을 제안하였다.

2) 이슈 할당받기

Project Maintainer와 협의가 되었다면, Issue를 할당받게 된다.

• 명시적으로 할당받지 않더라도 Maintainer와 다른 개발자들에게 적절하게 어필한 뒤, 시작하는 것도 좋아보인다.

3) 코드 컨텍스트 파악하기

코드를 작성하기 전, 해당 코드의 Context와 history를 파악해야한다. 필자는 아래의 방식으로 코드를 이해하였다.

1. UnitTest가 구현되어있는 경우, 이를 기반으로 로직 이해하기.
2. commit history, PR을 확인하여 history 파악하기.
3. 코드에 대한 의존성을 파악하기.

위 사항들을 진행한 결과 변경해야할 부분과 추가적으로 작성해야할 테스트코드의 위치 및 컨벤션을 쉽게 익힐 수 있었다.

4) 문제 해결하기

이제 코드를 작성할 시간이다. 아래의 것들을 주의하며 코드를 작성하였다.

1. 네이밍 컨벤션을 잘 지키고 있는가?
2. 코드 컨벤션을 잘 지키고 있는가?
3. 커밋 컨벤션을 잘 지키고 있는가?
4. 이미 추상화 되어있는 것을 또 다시 추상화 하고 있지 않은가?(Type 포함)
5. 테스트 코드나 문서도 함께 변경되어야 하는가?

코드를 작성하다보면, 내가 이걸 바꿔도 되나?라는 의문이 드는 부분이 발생하게 된다. 그럴땐...

5) 피드백 받기

조금이라도 애매한 부분은 Issue 및 PR에서 Maintainer와 함께 논의하는 것이 중요하다고 생각한다.

피드백 요청 예시 :

물론, Maintainer에게 피드백을 받을 수 없는 경우, 과감한 변경은 삼가는 것이 좋아보인다.

6) PR 생성하기

PR을 생성할 때, 정해진 템플릿에 맞춰 PR을 생성한다. 정해진 템플릿이 없다면 이전 PR들을 확인하여 따르는 것이 편하다.

1. PR Convention 맞추기(제목, 템플릿 등)
2. 해당 PR이 어떤 Issue를 기반으로 생성된 PR인지 명시하기
3. 해당 PR이 어떤 내용을 담고있는지 명시하기

> PR [#739]

7) Contribute 필수 요소 확인하기

또한, 변경사항이 merge되기 이전, 아래의 요소들을 확인해야한다.

1. build 확인하기
2. 테스트 통과 확인하기
3. CI test 확인하기
4. Contribute 요구사항 확인하기
5. 권리 계약서 서명하기(요구하는 경우에만)

보통 아래처럼 문서화 되어있는 경우가 대부분이다.

Contributer에게 제공되는 문서가 있다면, 해당 문서를 잘 읽어보자!

8) 4,5 단계 반복. 그리고 merge

필자의 경우 Maintainer분이 활발하게 피드백을 진행해주셨기에 수월하게 PR을 merge할 수 있었다.

Line에 관심이 많아 여러 프로젝트를 살펴봤었는데, 이렇게 기여까지 하게 되어 기쁠따름이다. 🥳

> Issue

> PR(Refactor Error)

+9) 추가 Issue 및 PR 생성하기

코드를 작성하다보니 UnitTest에 대한 개선 사항이 보여 추가적으로 개선을 제안했다.

(Mocha에서는 test.each 메서드를 지원하지 않아 forEach를 사용)

빠르게 merge 되었다.

> PR(Refactor UnitTest)

Opensource Study

한국의 오픈소스 생태계를 확장하고자 하는 인제님이 이끄시는 스터디이다. 인제님과 팀원들이 모여 본인이 원하는 프로젝트의 issue를 살펴보고 이를 해결하는 스프린트가 1주 동안 진행된다.

스터디엔 참가비가 있다. 원하는 오픈 소스에 50달러를 Sponsor하는 것이다.

인제님 뿐 아니라 팀원들 전부 열정과 낭만이 넘친다는 것을 느꼈고, 굉장히 많은 인사이트를 얻어갈 수 있었다.

매달 꾸준히 하실 예정이라고 하신다. 다음달에도 참여하는걸로! 😆

> 인제님의 오픈소스 블로그

> GDG Songdo 오픈소스 톡방

🥳👍