fix(checkbox): ensure to propagate invalid state to indicator

[noahchoii]

Related Issues

#617 (comment)

Description of Changes

@coderabbitai summary

• add invalid state to context
• enhance test cases

Checklist

Before submitting the PR, please make sure you have checked all of the following items.

• The PR title follows the Conventional Commits convention. (e.g., feat, fix, docs, style, refactor, test, chore)
• I have added tests for my changes.
• I have updated the Storybook or relevant documentation.
• I have added a changeset for this change. (e.g., for any changes that affect users, such as component prop changes or new features).
• I have performed a self-code review.
• I have followed the project's coding conventions and component patterns.

[changeset-bot]

🦋 Changeset detected

Latest commit: a5de0e3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@vapor-ui/core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
vapor-ui	Ready	Preview, Comment	Jun 16, 2026 7:37am

[coderabbitai]

Warning

Review limit reached

@noahchoii, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 12 minutes and 4 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 0c6c27d2-de56-4959-bc55-f14d417c1039

📥 Commits

Reviewing files that changed from the base of the PR and between 13feda3 and a5de0e3.

📒 Files selected for processing (3)

• .changeset/tired-clowns-walk.md
• packages/core/src/components/checkbox/checkbox.test.tsx
• packages/core/src/components/checkbox/checkbox.tsx

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch checkbox-invalid-context

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[vapor-ui]

✅ All tests passed!

Tests	Passed	Failed	Duration	Report
156	156	0	2m 57s	Open report ↗︎

Click here if you need to update snapshots.

[MaxLee-dev]

"I'm contemplating whether we need to test the propagation of disabled and readonly props from the root to the indicator, as this is inherently handled by the external library, base-ui.

When writing tests, I believe it's important to establish clear boundaries with external libraries. A good criterion for this boundary might be whether we are further processing or manipulating the props on our end.

For instance, we could leave the testing of disabled, which we don't directly control, to base-ui, and instead focus our tests on invalid and indeterminate, as we are actively managing and passing these states.

I would appreciate it if you could share your thoughts on this approach!"

[noahchoii]

@MaxLee-dev
댓글 남겨주신 부분에 대한 답변 드립니다!

말씀해주신 것처럼 "라이브러리의 코드는 안정적이다"는 전제 조건을 바탕으로 직접 테스트하지 않는 경우가 많은 것으로 알고, 충분히 공감도 됩니다! 다만 이는 라이브러리의 코드를 우리가 소비하는 상황일 때 가장 의미가 큰 것 같고, 이걸 그대로 다시 사용자에게 전달할 때는 다시 한 번 안정성을 점검할 필요가 있다고 생각했어요. 예를 들어 Base UI에서 특정 속성의 동작 방식을 수정했을 때, 이걸 따로 점검하지 않는다면 그대로 사용자에게 넘어가서 사용단에서 해당 문제가 드러나는 상황이 발생할 수 있어요.

이런 이유로 우리가 주요하게 사용하는 속성들에 대한 테스트 케이스는 따로 추가해둔 상황입니다! 이에 대해서 어떻게 생각하시나요?

[MaxLee-dev]

@noahchoii

말씀해주신 것처럼 "라이브러리의 코드는 안정적이다"는 전제 조건을 바탕으로 직접 테스트하지 않는 경우가 많은 것으로 알고, 충분히 공감도 됩니다! 다만 이는 라이브러리의 코드를 우리가 소비하는 상황일 때 가장 의미가 큰 것 같고, 이걸 그대로 다시 사용자에게 전달할 때는 다시 한 번 안정성을 점검할 필요가 있다고 생각했어요. 예를 들어 Base UI에서 특정 속성의 동작 방식을 수정했을 때, 이걸 따로 점검하지 않는다면 그대로 사용자에게 넘어가서 사용단에서 해당 문제가 드러나는 상황이 발생할 수 있어요.

이런 이유로 우리가 주요하게 사용하는 속성들에 대한 테스트 케이스는 따로 추가해둔 상황입니다! 이에 대해서 어떻게 생각하시나요?

저는 우리가 직접 꺼내서 제어하는 props에 대해서만 검증을 진행하는 것이 맞다고 생각했습니다. 물론 우리가 직접 다루지 않더라도 사용성이 높은 주요 props를 테스트 케이스에 추가하는 것 자체는 큰 문제가 없다고 봅니다.

처음에 의견을 드렸던 이유는, 단위 테스트가 컴포넌트의 명세서 역할을 할 수 있다고 생각했기 때문입니다. 우리가 실질적으로 지원(제어)하지 않는 기능이 테스트 명세에 포함되어 있으면, 사용자가 해당 기능을 우리 라이브러리 차원에서 공식 지원하는 것으로 오해할 수 있어서였습니다. 다만 이 부분이 기능상 크리티컬한 문제는 아니므로, 향후 테스트 케이스가 지나치게 많아질 때 다시 한번 논의해 보면 좋을 것 같습니다.