feat/#96 TextField 컴포넌트 구현

[ghdtjgus76]

용도 (Usage)

텍스트 입력을 위한 필드와 그에 따른 라벨, 오류 메시지, 설명 등을 함께 제공하여 입력 폼을 구성할 수 있는 컴포넌트입니다.

기능 (Props)

합성 컴포넌트 방식으로 구현했습니다.
아래 컴포넌트들을 적절히 조합해서 사용하시면 됩니다.

• Label: 텍스트필드의 라벨을 나타냅니다.
• Description: 텍스트필드의 설명 부분을 나타냅니다.
• Input: 텍스트필드의 input 요소를 나타냅니다.
• ErrorMessage: 텍스트필드의 에러 메시지를 나타냅니다.
• LeftContent: 텍스트필드 왼쪽에 들어가는 요소를 나타냅니다.
• RightContent: 텍스트필드 오른쪽에 들어가는 요소를 나타냅니다.

TextField에는 children, isInvalid를 props로 받도록 하였는데, isInvalid의 경우 input 전체적으로 상태를 공유해야 될 거 같다는 생각에 추가했습니다.
나머지는 각 하위 컴포넌트에서 props를 제어할 수 있도록 구성했습니다.

Input 컴포넌트에는 제어/비제어 컴포넌트를 고려하여 props를 구성하였습니다.
제어/비제어에 대한 제어는 별도 훅으로 관리하면 다른 컴포넌트에도 사용할 수 있을 거 같아 useControlledValue 훅을 작성했습니다.

참고 (Reference)

마일스톤 (Milestones)

---

저번 회의 때 말씀 드린 스토리북 합성 컴포넌트 관련 문서화를 해결하기 위한 방법을 아직 찾지 못해서 해당 부분은 문서화 제외하고 올려둡니다.
조금 더 찾아보겠습니다

Summary by CodeRabbit

• 새로운 기능

  • useControlledValue 훅 추가: 폼 입력의 상태를 관리하는 기능 제공.
  • useSafeContext 훅 추가: 안전한 컨텍스트 사용을 위한 기능 제공.
  • TextField 컴포넌트 및 하위 컴포넌트 추가: 텍스트 필드와 관련된 다양한 기능 제공.
  • Divider 컴포넌트 추가: 수평 및 수직 구분선 렌더링 기능 제공.

• 문서화

  • @warrr-ui/text-field 컴포넌트에 대한 README 파일 추가.
  • Divider 컴포넌트에 대한 Storybook 스토리 추가.
  • TextField 컴포넌트에 대한 Storybook 스토리 추가.

• 테스트

  • TextField 컴포넌트에 대한 단위 테스트 및 E2E 테스트 추가.
  • Divider 컴포넌트에 대한 Storybook 테스트 추가.

[coderabbitai]

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (1)

e2e/components/primitive/text-field.test.ts (1)

1-5: [제안] import 구문 정리

테스트 코드에서 사용하지 않는 모듈이나 불필요한 공백이 있을 수 있습니다. import 구문을 정리하여 코드의 가독성을 높여주세요.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 44667a1 and 9490a7a.

📒 Files selected for processing (1)

• e2e/components/primitive/text-field.test.ts (1 hunks)

🧰 Additional context used

[coderabbitai]

🛠️ Refactor suggestion

[반복되는 코드 리팩토링 제안]

여러 테스트에서 동일한 패턴의 코드가 반복되고 있습니다. 이를 함수로 추출하여 테스트 코드를 더욱 간결하고 유지보수하기 쉽게 만들 수 있습니다.

예를 들어, 시각적 회귀 테스트와 접근성 테스트를 위한 공통 함수를 생성합니다:

async function runVisualRegressionTest(page: Page, id: string) {
  await visit(page, { id });
  await expect(page).toHaveScreenshot();
}

async function runAccessibilityTest(page: Page, id: string) {
  await visit(page, { id });
  const accessibilityScanResults = await axeAccessibilityScan(page);
  expect(accessibilityScanResults.violations).toEqual([]);
}

그리고 각 테스트에서 다음과 같이 사용합니다:

-test("시각적 회귀 테스트를 통과해야 합니다.", async ({ page }: { page: Page }) => {
-  await visit(page, {
-    id: "ui-text-field--default",
-  });
-
-  await expect(page).toHaveScreenshot();
-});
+test("Default 변형의 시각적 회귀 테스트를 통과해야 합니다.", async ({ page }) => {
+  await runVisualRegressionTest(page, "ui-text-field--default");
+});

---

⚠️ Potential issue

[중복된 테스트 함수 이름 수정 필요]

테스트 함수들이 모두 동일한 이름("시각적 회귀 테스트를 통과해야 합니다.", "axe를 사용한 웹 접근성 테스트를 통과해야 합니다.")을 사용하고 있습니다. 이는 테스트 결과를 해석할 때 혼동을 줄 수 있습니다. 각 테스트 함수의 이름을 고유하게 변경하여 어떤 변형(variant)을 테스트하는지 명확히 나타내주세요.

예를 들어, 다음과 같이 수정할 수 있습니다:

-test("시각적 회귀 테스트를 통과해야 합니다.", async ({ page }: { page: Page }) => {
+test("Default 변형의 시각적 회귀 테스트를 통과해야 합니다.", async ({ page }: { page: Page }) => {

Committable suggestion was skipped due to low confidence.

[github-actions]

VRT 테스트 성공

VRT 테스트가 성공적으로 완료되었습니다.

[github-actions]

🐱 스토리북이 배포되었습니다: https://www.chromatic.com/build?appId=667edcfe9b923ba1892556f4&number=74 🐱

[coderabbitai]

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (2)

packages/primitive/components/text-field/stories/text-field.stories.tsx (2)

1-20: 메타 설정과 임포트가 잘 구성되어 있습니다.

전반적으로 임포트와 메타 설정이 잘 되어 있습니다. Storybook 구성에 필요한 모든 요소가 포함되어 있고, 컴포넌트 부제목이 한국어로 제공되어 있어 적절합니다.

일관성을 위해 argTypes 객체에 TextField 컴포넌트의 주요 props에 대한 설명을 추가하는 것을 고려해 보세요. 예를 들어:

argTypes: {
  isInvalid: {
    description: '입력 필드의 유효성 상태를 나타냅니다.',
    control: 'boolean',
  },
  // 다른 주요 props에 대한 설명 추가
},

이렇게 하면 Storybook에서 컴포넌트의 props를 더 쉽게 이해하고 조작할 수 있습니다.

---

22-158: 스토리의 구조와 커버리지가 우수합니다.

TextField 컴포넌트의 다양한 기능과 사용 사례를 잘 보여주는 스토리들이 구성되어 있습니다. 기본 사용법부터 플레이스홀더, 기본값, 제어된 입력, 커스텀 입력 타입, 라벨, 설명, 에러 메시지, 콘텐츠 위치 등 다양한 측면을 다루고 있어 좋습니다.

WithCustomInputType 스토리 개선 제안

WithCustomInputType 스토리에서 이메일 유효성 검사를 개선할 수 있습니다.

현재 패턴 "[email protected]"은 gmail.com 주소만 허용합니다. 더 일반적인 이메일 패턴을 사용하는 것이 좋겠습니다. 예를 들어:

pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"

이 패턴은 더 넓은 범위의 유효한 이메일 주소를 허용합니다.

WithLeftContent와 WithRightContent 스토리 수정 확인

이전 리뷰에서 지적된 WithLeftContent와 WithRightContent 스토리의 불일치 문제가 해결되었습니다. 현재 구현은 스토리 이름과 일치하며, 각각 올바른 위치에 콘텐츠를 배치하고 있습니다. 잘 수정되었습니다.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 9490a7a and 99f3b3c.

📒 Files selected for processing (3)

• packages/primitive/components/text-field/src/text-field.tsx (1 hunks)
• packages/primitive/components/text-field/stories/text-field.stories.tsx (1 hunks)
• turbo/generators/templates/e2e/test.ts.hbs (1 hunks)

🧰 Additional context used

🔇 Additional comments (7)

turbo/generators/templates/e2e/test.ts.hbs (1)

9-9: 변경 사항이 일관성 있게 적용되었습니다.

컴포넌트 이름에 kebabCase를 적용하는 변경이 두 테스트 케이스에 일관되게 적용되었습니다. 이는 이름 지정 규칙을 개선하고 가독성을 높일 것으로 보입니다.

다만, 이 변경이 기존 테스트나 컴포넌트에 미치는 영향을 확인해 주시기 바랍니다. 다음 스크립트를 실행하여 kebabCase 함수의 사용을 확인할 수 있습니다:

Also applies to: 17-17

✅ Verification successful

변경 사항이 성공적으로 검증되었습니다.

kebabCase 함수의 사용이 코드베이스 전체에서 일관되게 적용되고 있음을 확인했습니다. 따라서 변경 사항에 문제가 없음을 확인했습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# kebabCase 함수의 사용을 확인합니다.
rg --type typescript "kebabCase" -g '!**/node_modules/**'

Length of output: 92

---

Script:

#!/bin/bash
# kebabCase 함수의 사용을 확인합니다.
rg --type ts "kebabCase" -g '!**/node_modules/**'

Length of output: 352

packages/primitive/components/text-field/src/text-field.tsx (5)

1-5: import 문이 적절히 구성되어 있습니다.

필요한 React 타입과 함수, 그리고 커스텀 훅들이 올바르게 임포트되어 있습니다. 이는 컴포넌트의 기능을 구현하는 데 필요한 요소들을 잘 포함하고 있습니다.

---

31-92: 서브컴포넌트들이 잘 구현되어 있습니다.

Label, Description, Input, ErrorMessage, LeftContent, RightContent 등의 서브컴포넌트들이 React 모범 사례를 따라 잘 구현되어 있습니다. 특히:

1. Input 컴포넌트가 useControlledValue 훅을 사용하여 제어 및 비제어 상태를 모두 처리하고 있습니다.
2. ErrorMessage 컴포넌트가 컨텍스트 값을 적절히 사용하여 조건부 렌더링을 수행합니다.
3. 각 컴포넌트가 필요한 props를 올바르게 처리하고 있습니다.

이러한 구현은 TextField 컴포넌트의 유연성과 재사용성을 높여줍니다.

---

94-101: TextField 컴포넌트의 구성이 잘 되어 있습니다.

Object.assign을 사용하여 TextField 컴포넌트를 구성한 방식이 매우 적절합니다. 이 패턴은 다음과 같은 이점을 제공합니다:

1. 깔끔하고 직관적인 API를 제공합니다.
2. 사용자가 TextField.Label, TextField.Input 등과 같이 점 표기법을 통해 서브컴포넌트에 쉽게 접근할 수 있게 합니다.
3. 컴포넌트의 구조를 명확하게 표현하여 코드의 가독성을 높입니다.

이러한 구성은 컴포넌트의 사용성과 유지보수성을 크게 향상시킵니다.

---

103-103: 기본 내보내기가 적절히 사용되었습니다.

TextField 컴포넌트를 기본 내보내기로 설정한 것은 적절합니다. 이는 이 파일의 주요 컴포넌트임을 명확히 하고, 가져오는 쪽에서 원하는 이름으로 쉽게 임포트할 수 있게 해줍니다.

---

105-111: displayName 속성이 적절히 설정되어 있습니다.

모든 컴포넌트와 서브컴포넌트에 대해 displayName을 설정한 것은 매우 좋습니다. 특히:

1. "WarrrUI.ComponentName" 형식의 일관된 명명 패턴을 사용하고 있어, 컴포넌트 식별이 용이합니다.
2. 이는 React DevTools에서 컴포넌트를 쉽게 식별할 수 있게 해주어 디버깅과 개발 과정을 원활하게 합니다.
3. 프로젝트의 네이밍 컨벤션을 잘 따르고 있어 코드의 일관성을 유지하고 있습니다.

이러한 displayName 설정은 개발 경험을 향상시키는 좋은 사례입니다.

packages/primitive/components/text-field/stories/text-field.stories.tsx (1)

1-158: 종합 평가: TextField 스토리북 파일이 잘 구성되어 있습니다.

이 스토리북 파일은 TextField 컴포넌트의 다양한 기능과 사용 사례를 포괄적으로 다루고 있습니다. 기본 사용법부터 고급 기능까지 잘 구현되어 있으며, 이전 리뷰에서 지적된 문제점들도 적절히 해결되었습니다.

개선을 위한 몇 가지 제안:

1. argTypes에 주요 props에 대한 설명 추가
2. 이메일 유효성 검사 패턴 개선

이러한 minor한 개선점들을 적용하면 더욱 완성도 높은 스토리북이 될 것 같습니다. 전반적으로 훌륭한 작업입니다!

[coderabbitai]

🛠️ Refactor suggestion

컨텍스트에 기본값을 제공하는 것이 좋습니다.

TextFieldContext를 생성할 때 null 대신 기본값을 제공하는 것이 좋습니다. 이렇게 하면 컨텍스트를 사용하는 컴포넌트에서 항상 유효한 값을 가질 수 있습니다.

다음과 같이 변경을 고려해보세요:

- const TextFieldContext = createContext<TextFieldContextProps | null>(null);
+ const TextFieldContext = createContext<TextFieldContextProps>({ isInvalid: false });

이렇게 하면 useSafeContext 훅을 사용할 때 타입 안전성이 향상되고, 컴포넌트 외부에서 Provider 없이 사용하는 경우에도 안전합니다.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	interface TextFieldContextProps {
	isInvalid: boolean;
	}
	const TextFieldContext = createContext<TextFieldContextProps | null>(null);
	interface TextFieldContextProps {
	isInvalid: boolean;
	}
	const TextFieldContext = createContext<TextFieldContextProps>({ isInvalid: false });

[coderabbitai]

🛠️ Refactor suggestion

TextFieldRoot 컴포넌트의 유연성 개선이 필요합니다.

TextFieldRoot 컴포넌트가 forwardRef를 올바르게 사용하고 있고 컨텍스트 제공자도 잘 구현되어 있습니다. 하지만, 추가적인 props를 루트 div 요소에 전달하지 않아 컴포넌트의 유연성이 제한될 수 있습니다.

다음과 같이 변경을 제안합니다:

const TextFieldRoot = forwardRef<HTMLDivElement, TextFieldProps>(
  (props, ref: ForwardedRef<HTMLDivElement>) => {
-   const { children, isInvalid = false } = props;
+   const { children, isInvalid = false, ...restProps } = props;
    const contextValue = { isInvalid };

    return (
      <TextFieldContext.Provider value={contextValue}>
-       <div ref={ref}>{children}</div>
+       <div ref={ref} {...restProps}>{children}</div>
      </TextFieldContext.Provider>
    );
  }
);

이렇게 하면 사용자가 TextFieldRoot에 추가적인 props를 전달할 수 있어 더 유연한 사용이 가능해집니다.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const TextFieldRoot = forwardRef<HTMLDivElement, TextFieldProps>(
	(props, ref: ForwardedRef<HTMLDivElement>) => {
	const { children, isInvalid = false } = props;
	const contextValue = { isInvalid };
	return (
	<TextFieldContext.Provider value={contextValue}>
	<div ref={ref}>{children}</div>
	</TextFieldContext.Provider>
	);
	}
	);
	const TextFieldRoot = forwardRef<HTMLDivElement, TextFieldProps>(
	(props, ref: ForwardedRef<HTMLDivElement>) => {
	const { children, isInvalid = false, ...restProps } = props;
	const contextValue = { isInvalid };
	return (
	<TextFieldContext.Provider value={contextValue}>
	<div ref={ref} {...restProps}>{children}</div>
	</TextFieldContext.Provider>
	);
	}
	);

[gs0428]

리드미 채워주세요!

[gs0428]

이것도 채워주세요!

[coderabbitai]

Actionable comments posted: 8

🧹 Outside diff range and nitpick comments (8)

README.md (2)

7-12: 철학 섹션이 잘 구성되어 있습니다.

warrr-ui의 핵심 가치를 명확하게 전달하고 있습니다. 각 요점이 잘 설명되어 있고, 중요한 개념을 강조하기 위해 굵은 글씨를 효과적으로 사용하고 있습니다.

개선 제안: 각 철학 포인트에 이모지를 추가하여 시각적 흥미를 더할 수 있습니다. 예를 들어:

• 🚀 와르르르한 개발 경험
• 🤝 커뮤니티 중심
• 🌐 사용자 경험

이렇게 하면 각 포인트가 더욱 눈에 띄고 기억하기 쉬워질 것 같습니다.

---

14-18: 제공 내용 섹션이 명확하게 작성되었습니다.

warrr-ui가 제공하는 내용과 목표를 잘 설명하고 있습니다. 개발자들이 이 디자인 시스템을 통해 얻을 수 있는 이점을 명확히 전달하고 있습니다.

개선 제안: 이 섹션의 끝에 간단한 예시나 사용 사례를 추가하면 좋을 것 같습니다. 예를 들어:

"예를 들어, warrr-ui를 사용하면 복잡한 폼 구현 시간을 50% 이상 단축할 수 있습니다."

이런 구체적인 예시를 통해 개발자들이 warrr-ui의 실제 이점을 더 쉽게 이해할 수 있을 것 같습니다.

turbo/generators/templates/e2e/test.ts.hbs (2)

7-13: LGTM: 적절한 시각적 회귀 테스트 구현

시각적 회귀 테스트가 올바르게 구현되었습니다. Storybook 페이지 방문과 스크린샷 비교 방식이 적절합니다.

개선 제안: 테스트의 안정성을 높이기 위해 스크린샷 비교 전에 페이지가 완전히 로드되었는지 확인하는 단계를 추가하는 것이 좋습니다. 예를 들어:

await page.waitForSelector('.some-unique-element');

이렇게 하면 비동기 로딩으로 인한 잠재적인 오류를 방지할 수 있습니다.

---

15-22: LGTM: 웹 접근성 테스트 구현 적절

axe를 사용한 웹 접근성 테스트가 잘 구현되었습니다. 접근성 위반 사항이 없어야 한다는 엄격한 기준을 적용한 것이 좋습니다.

개선 제안: 접근성 테스트 결과에 대해 더 자세한 정보를 로깅하는 것이 도움이 될 수 있습니다. 예를 들어:

expect(accessibilityScanResults.violations).toEqual([]);
if (accessibilityScanResults.violations.length > 0) {
  console.log('접근성 위반 사항:', JSON.stringify(accessibilityScanResults.violations, null, 2));
}

이렇게 하면 테스트 실패 시 디버깅이 더 쉬워질 것입니다.

packages/primitive/components/divider/stories/divider.stories.tsx (1)

5-23: 메타데이터가 잘 정의되었습니다.

Storybook을 위한 Divider 컴포넌트의 메타데이터가 잘 구성되어 있습니다. 한국어로 된 부제목은 한국어 사용자에게 유용할 것입니다. 'orientation' prop의 정의도 적절합니다.

개선 제안:

• 일관성을 위해 argTypes의 description도 한국어로 작성하는 것이 좋겠습니다.

package.json (1)

7-13: 스크립트 변경 및 추가가 적절합니다.

format과 lint 스크립트에 --cache 옵션을 추가한 것은 성능 향상에 도움이 됩니다. 새로 추가된 스크립트들은 개발 프로세스를 잘 지원하고 있습니다. 특히 e2e 테스트 스크립트의 추가는 컴포넌트 기능을 보장하는 데 큰 도움이 될 것입니다.

개선 제안: test 스크립트에도 --cache 옵션을 추가하는 것을 고려해 보세요. 이는 대규모 테스트 스위트에서 성능을 향상시킬 수 있습니다.

-    "test": "jest --verbose --config ./jest.config.ts"
+    "test": "jest --verbose --config ./jest.config.ts --cache"

.github/workflows/release.yml (2)

31-48: pnpm 설정과 캐싱이 잘 구현되어 있습니다.

특정 버전의 pnpm을 사용하여 일관성을 보장하고, 의존성 캐싱을 통해 워크플로우 속도를 개선한 점이 좋습니다. 캐시 키에 pnpm-lock.yaml 해시를 포함한 것도 좋은 방법입니다.

.npmrc 파일 생성 단계에서 보안을 강화하기 위해 다음과 같이 수정을 고려해 보세요:

- run: echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > .npmrc
+ run: |
+   echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > .npmrc
+   chmod 600 .npmrc

이렇게 하면 .npmrc 파일의 권한을 제한하여 보안을 강화할 수 있습니다.

---

55-64: 버전 업데이트 및 npm 배포 단계가 잘 구성되어 있습니다.

changesets를 사용하여 버전 관리와 변경 로그를 자동화한 것이 좋습니다. 인증에 시크릿을 사용하여 보안을 유지하고 있습니다.

명확성을 위해 커밋 메시지에 버전 번호를 포함하는 것을 고려해 보세요. 예를 들어:

- title: "chore: 버전 업데이트"
- commit: "chore: 버전 업데이트"
+ title: "chore: 버전 업데이트 v${{ steps.package-version.outputs.version }}"
+ commit: "chore: 버전 업데이트 v${{ steps.package-version.outputs.version }}"

이를 위해 버전을 가져오는 단계를 추가해야 합니다:

- name: 패키지 버전 가져오기
  id: package-version
  run: echo "version=$(node -p "require('./package.json').version")" >> $GITHUB_OUTPUT

이렇게 하면 각 릴리스의 버전을 더 쉽게 식별할 수 있습니다.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 99f3b3c and f827fe7.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (11)

• .changeset/README.md (1 hunks)
• .changeset/big-eggs-crash.md (1 hunks)
• .changeset/config.json (1 hunks)
• .github/workflows/label-vrt-update.yml (1 hunks)
• .github/workflows/release.yml (1 hunks)
• README.md (1 hunks)
• package.json (1 hunks)
• packages/primitive/components/divider/src/divider.tsx (1 hunks)
• packages/primitive/components/divider/stories/divider.stories.tsx (1 hunks)
• turbo/generators/templates/component/tests/{{kebabCase componentName}}.test.tsx.hbs (1 hunks)
• turbo/generators/templates/e2e/test.ts.hbs (1 hunks)

✅ Files skipped from review due to trivial changes (3)

• .changeset/README.md
• .changeset/big-eggs-crash.md
• .changeset/config.json

🚧 Files skipped from review as they are similar to previous changes (1)

• turbo/generators/templates/component/tests/{{kebabCase componentName}}.test.tsx.hbs

🧰 Additional context used

🪛 actionlint

.github/workflows/label-vrt-update.yml

78-78: "github.head_ref" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions for more details

(expression)

🔇 Additional comments (14)

README.md (2)

1-5: 제목과 소개가 잘 작성되었습니다.

환영 메시지와 warrr-ui에 대한 소개가 명확하고 간결하게 작성되어 있습니다. 디자인 시스템의 목적과 목표를 잘 설명하고 있어 사용자들이 쉽게 이해할 수 있을 것 같습니다.

---

1-18: 전반적으로 우수한 README 파일입니다.

이 README는 warrr-ui 디자인 시스템에 대해 포괄적이고 명확한 소개를 제공하고 있습니다. 구조가 잘 잡혀 있고, 정보가 풍부하며, 읽기 쉽게 작성되어 있습니다. 제안된 minor 개선사항들을 적용하면 더욱 훌륭한 문서가 될 것 같습니다.

사용자들이 warrr-ui의 가치와 이점을 쉽게 이해할 수 있도록 잘 작성되었습니다. 훌륭한 작업입니다!

turbo/generators/templates/e2e/test.ts.hbs (2)

1-4: LGTM: 적절한 임포트 구문

필요한 Playwright 테스트 유틸리티와 커스텀 유틸리티 함수들이 올바르게 임포트되었습니다.

---

6-6: LGTM: 명확한 테스트 스위트 설명

테스트 스위트 설명이 명확하며, {{componentName}} 템플릿 변수를 사용하여 다양한 컴포넌트에 대해 재사용 가능하도록 구성되었습니다.

packages/primitive/components/divider/stories/divider.stories.tsx (2)

1-3: 임포트가 올바르게 구성되었습니다.

필요한 Storybook 타입과 Divider 컴포넌트가 정확하게 임포트되었습니다. 코드가 간결하고 목적에 맞게 작성되었습니다.

---

25-27: 스토리 타입 정의가 올바릅니다.

메타데이터의 기본 내보내기와 Story 타입 정의가 Storybook의 모범 사례를 따르고 있습니다. 이는 타입 안정성을 보장하고 개발 경험을 향상시킵니다.

package.json (3)

2-2: 패키지 이름 변경이 적절합니다.

스코프가 있는 패키지 이름으로 변경한 것은 좋은 선택입니다. 이는 관련 패키지를 구성하는 데 도움이 되며 현대적인 npm 패키지 명명 규칙을 따릅니다.

---

48-49: 엔진 사양 변경이 적절합니다.

pnpm의 정확한 버전을 지정한 것은 좋은 선택입니다. 이는 개발 환경 간의 일관성을 보장하며, 대규모 프로젝트의 패키지 관리 모범 사례를 따르고 있습니다.

---

16-25: devDependencies 변경이 적절합니다.

새로 추가된 개발 의존성들은 TextField 컴포넌트의 구현과 테스팅을 잘 지원할 것으로 보입니다. 특히 다양한 테스팅 라이브러리의 추가는 철저한 테스트 관행을 따르고 있음을 보여줍니다. @changesets/cli의 추가는 체계적인 버전 관리 전략을 도입하려는 의도로 보입니다.

고려사항: 일부 패키지 버전이 ^로 지정되어 있습니다. 프로젝트의 안정성을 위해 중요한 의존성의 경우 정확한 버전을 지정하는 것을 고려해보세요. 다음 스크립트를 실행하여 현재 사용 중인 정확한 버전을 확인할 수 있습니다:

이 정보를 바탕으로 중요한 의존성의 버전을 고정할 수 있습니다.

Also applies to: 28-28, 34-37, 39-41, 44-44

.github/workflows/release.yml (3)

1-8: 워크플로우 이름과 트리거 설정이 적절합니다.

워크플로우 이름이 목적을 명확히 설명하고 있으며, 메인 브랜치에 푸시될 때 트리거되는 설정이 릴리스 워크플로우에 적합합니다. CI 환경 변수를 true로 설정한 것도 좋은 관행입니다.

---

50-53: 의존성 설치 단계가 커스텀 스크립트를 사용하고 있습니다.

커스텀 스크립트를 사용하면 필요한 경우 더 복잡한 설치 로직을 구현할 수 있어 유연성이 높습니다.

스크립트 실행 권한 설정을 스크립트 내부로 옮기는 것을 고려해 보세요. 예를 들어:

- run: |
-   chmod +x ./scripts/install-dependencies.sh
-   ./scripts/install-dependencies.sh
+ run: ./scripts/install-dependencies.sh

그리고 install-dependencies.sh 스크립트의 첫 줄에 다음을 추가하세요:

chmod +x "${0}"

./scripts/install-dependencies.sh 스크립트의 내용과 동작을 확인해 주세요. 다음 명령어로 스크립트 내용을 확인할 수 있습니다:

---

10-29: 작업 설정과 초기 단계가 잘 구성되어 있습니다.

작업 구성이 적절하며, 체크아웃 단계에서 fetch-depth: 0을 사용하여 전체 히스토리를 가져오는 것이 버전 관리에 좋습니다. Node.js 설정도 환경 변수를 사용하여 유연성을 제공합니다.

환경 변수 설정에 사용되는 커스텀 스크립트 ./scripts/set-env.sh의 내용과 동작을 확인해 주세요. 다음 명령어로 스크립트 내용을 확인할 수 있습니다:

.github/workflows/label-vrt-update.yml (2)

1-9: 워크플로우 트리거 및 작업 설정이 적절합니다.

워크플로우 이름, 트리거 조건, 그리고 'VRT' 라벨에 대한 조건부 실행이 잘 구성되어 있습니다. 이는 필요한 경우에만 워크플로우가 실행되도록 하여 리소스를 효율적으로 사용합니다.

---

85-107: PR 코멘트 작성 및 라벨 제거 로직이 적절합니다.

GitHub API와의 상호 작용을 위해 actions/github-script를 사용한 것은 좋은 선택입니다. PR에 코멘트를 추가하고 'VRT' 라벨을 제거하는 로직이 잘 구현되어 있습니다.

[coderabbitai]

🛠️ Refactor suggestion

Horizontal 스토리가 잘 정의되었지만, 개선의 여지가 있습니다.

Horizontal 스토리의 기본 구조는 잘 정의되었습니다. 하지만 스타일 값이 하드코딩되어 있어 유연성이 제한될 수 있습니다.

개선 제안:

• 하드코딩된 스타일 값(예: 너비, 높이, 배경색) 대신 디자인 토큰이나 테마 변수를 사용하는 것이 좋습니다. 이렇게 하면 유지보수성이 향상되고 디자인 시스템과의 일관성을 유지할 수 있습니다.

예시:

export const Horizontal: Story = {
  args: {
    style: {
      width: "100%",
      height: theme.spacing.xxs,
      backgroundColor: theme.colors.divider,
    },
  },
};

[coderabbitai]

🛠️ Refactor suggestion

Vertical 스토리의 개선 가능성이 있습니다.

Vertical 스토리의 기본 구조와 'orientation' 설정은 적절합니다. 하지만 Horizontal 스토리와 마찬가지로 스타일 값이 하드코딩되어 있고, 고정된 높이가 모든 사용 사례에 적합하지 않을 수 있습니다.

개선 제안:

1. 디자인 토큰이나 테마 변수를 사용하여 스타일 값을 정의하세요.
2. 높이를 더 유연하게 설정할 수 있도록 하세요. 예를 들어, 부모 컨테이너의 높이에 따라 조절되도록 할 수 있습니다.

예시:

export const Vertical: Story = {
  args: {
    orientation: "vertical",
    style: {
      width: theme.spacing.xxs,
      height: "100%", // 부모 컨테이너의 높이에 맞춤
      backgroundColor: theme.colors.divider,
    },
  },
};

이렇게 수정하면 다양한 레이아웃에서 더 유연하게 사용할 수 있는 Vertical Divider를 표현할 수 있습니다.

[coderabbitai]

⚠️ Potential issue

스크립트 실행 보안 개선 필요

현재 스크립트 실행 방식에 보안 취약점이 있을 수 있습니다. chmod +x 명령어를 사용하여 스크립트를 실행 가능하게 만든 후 직접 실행하는 대신, 더 안전한 방법을 사용하는 것이 좋습니다.

다음과 같이 개선할 것을 제안합니다:

- chmod +x ./scripts/set-env.sh
- ./scripts/set-env.sh
+ sh ./scripts/set-env.sh

- chmod +x ./scripts/install-dependencies.sh
- ./scripts/install-dependencies.sh
+ sh ./scripts/install-dependencies.sh

- chmod +x ./scripts/install-playwright.sh
- ./scripts/install-playwright.sh
+ sh ./scripts/install-playwright.sh

이렇게 하면 스크립트에 실행 권한을 부여하지 않고도 안전하게 실행할 수 있습니다.

Also applies to: 51-59

[coderabbitai]

🛠️ Refactor suggestion

Storybook 빌드 및 실행 프로세스 개선 제안

현재 구현은 기본적으로 잘 작동하지만, 오류 처리와 프로세스 관리 측면에서 개선의 여지가 있습니다.

다음과 같은 개선을 제안합니다:

1. Storybook 빌드 실패 시 워크플로우를 중단하도록 설정:

- name: 스토리북 빌드
  run: pnpm run build-storybook
  working-directory: packages/primitive
  if: success()

2. 백그라운드 프로세스 관리 개선:

- name: 스토리북 실행
  run: |
    npx serve -l 6006 packages/primitive/storybook-static &
    echo $! > .storybook-pid
    sleep 5  # 서버가 완전히 시작될 때까지 대기
    if ! curl -s http://localhost:6006 > /dev/null; then
      echo "스토리북 서버 시작 실패"
      exit 1
    fi

이러한 변경으로 프로세스의 안정성과 오류 처리 능력이 향상될 것입니다.

[coderabbitai]

🛠️ Refactor suggestion

스냅샷 업데이트 프로세스 개선 필요

현재 스냅샷 업데이트 과정이 간단하게 구현되어 있지만, 오류 처리와 결과 보고 메커니즘이 부족합니다.

다음과 같은 개선을 제안합니다:

- name: 스냅샷 업데이트
  run: |
    if ! pnpm run e2e:update; then
      echo "스냅샷 업데이트 실패"
      exit 1
    fi
    if [[ -n $(git status --porcelain .playwright) ]]; then
      echo "스냅샷이 업데이트되었습니다."
    else
      echo "업데이트된 스냅샷이 없습니다."
    fi

이렇게 하면 스냅샷 업데이트 실패 시 워크플로우가 중단되고, 업데이트 여부를 명확히 알 수 있습니다.

[coderabbitai]

⚠️ Potential issue

Git 작업 보안 개선 필요

현재 구현에서 github.head_ref를 직접 사용하여 Git push를 수행하고 있습니다. 이는 잠재적인 보안 위험을 초래할 수 있습니다.

다음과 같이 개선할 것을 제안합니다:

1. github.head_ref를 환경 변수로 전달:

- name: 변경된 스냅샷 커밋 및 푸시
  env:
    HEAD_REF: ${{ github.head_ref }}
  run: |
    git config --local user.email "[email protected]"
    git config --local user.name "GitHub Action"
    git add .playwright
    git diff --staged --quiet || git commit -m "Update VRT snapshots in .playwright folder"
    git push origin HEAD:$HEAD_REF

이렇게 하면 인라인 스크립트에서 직접 github.head_ref를 사용하는 대신 환경 변수를 통해 안전하게 참조할 수 있습니다.

🧰 Tools

🪛 actionlint

78-78: "github.head_ref" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions for more details

(expression)

[coderabbitai]

🛠️ Refactor suggestion

⚠️ Potential issue

공용 Props 타입으로 인한 충돌 가능성

DivProps와 HrProps를 모두 합친 DividerProps는 div와 hr 엘리먼트의 속성이 충돌할 수 있습니다. 두 엘리먼트는 서로 다른 속성을 가지므로, orientation에 따라 적절한 Props를 적용하도록 타입을 분리하는 것이 좋습니다.

다음과 같이 orientation에 따라 조건부 타입을 적용할 수 있습니다:

-export type DividerProps = DivProps &
-  HrProps & {
-    orientation?: Orientation;
-  };
+type BaseDividerProps = {
+  orientation?: Orientation;
+};
+
+type HorizontalDividerProps = HrProps & {
+  orientation?: "horizontal";
+};
+
+type VerticalDividerProps = DivProps & {
+  orientation?: "vertical";
+};
+
+export type DividerProps = BaseDividerProps &
+  (HorizontalDividerProps | VerticalDividerProps);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	export type DividerProps = DivProps &
	HrProps & {
	orientation?: Orientation;
	};
	type BaseDividerProps = {
	orientation?: Orientation;
	};
	type HorizontalDividerProps = HrProps & {
	orientation?: "horizontal";
	};
	type VerticalDividerProps = DivProps & {
	orientation?: "vertical";
	};
	export type DividerProps = BaseDividerProps &
	(HorizontalDividerProps | VerticalDividerProps);

[coderabbitai]

🛠️ Refactor suggestion

⚠️ Potential issue

typedRef의 타입 정의 오류

typedRef의 타입 선언에서 typeof orientation extends "vertical" 표현은 원하는 결과를 얻지 못합니다. typeof orientation은 언제나 string 타입이므로, 이 조건은 항상 참입니다. 대신 isVertical 변수를 활용하여 조건부 타입을 적용하는 것이 바람직합니다.

다음과 같이 수정할 수 있습니다:

-const typedRef = ref as ForwardedRef<
-  typeof orientation extends "vertical" ? HTMLDivElement : HTMLHRElement
->;
+const typedRef = ref as ForwardedRef<
+  typeof Component extends "div" ? HTMLDivElement : HTMLHRElement
+>;

또는 더 간단하게:

-const typedRef = ref as ForwardedRef<
-  typeof orientation extends "vertical" ? HTMLDivElement : HTMLHRElement
->;
+const typedRef = ref as ForwardedRef<
+  HTMLDivElement | HTMLHRElement
+>;

Committable suggestion was skipped due to low confidence.

[minai621]

테스트 이름이 똑같으면 나중에 특정 테스트만 실행할 때, 중복이 있어서 문제가 있을 수 있을 것 같아요.
storybook의 생성되는 story-id를 사용해서 작명하는걸로 토론해보면 좋을 것 같아요.

[minai621]

반대로 에러 상태가 아닌 경우 에러메시지가 표시되지 않는 테스트가 있어야 할 것 같아요.

Suggested change

	it("에러 상태인 경우 에러 메시지가 정상적으로 표시되어야 합니다.", () => {
	it("에러 상태가 아닌 경우 에러 메시지가 표시되지 말아야 합니다.", () => {
	const screen = render(
	<TextField>
	<TextField.Input />
	<TextField.ErrorMessage>에러가 발생했습니다.</TextField.ErrorMessage>
	</TextField>
	);
	const errorMessage = screen.queryByText("에러가 발생했습니다.");
	expect(errorMessage).not.toBeInTheDocument();
	});

[minai621]

동적으로 Description을 감출 수 있는 방법이 있을까요?
TextField에 focus가 들어온 상태에서 등.. description을 감춰야 하는 상황이 올 수 있을 것 같은데 어떠신가요?