-
Notifications
You must be signed in to change notification settings - Fork 424
docs: improve grammar in blog/elysia-02.md #635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughEdits are limited to a single blog post file, applying copy and grammar fixes, pluralization and consistency adjustments, and refined descriptions in OpenAPI/Schema sections. No structural, feature, or code/API changes were made. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests
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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (7)
docs/blog/elysia-02.md (7)
75-78: Prefer lowercase “schema” for consistency.
Use “schema fields” unless referring to a proper API object.Apply this diff:
-Now Elysia can memorize schemas and reference them directly in Schema fields, without creating an import file via `Elysia.setModel`. +Now Elysia can memorize schemas and reference them directly in schema fields, without creating an import file via `Elysia.setModel`.
109-116: OpenAPI terminology may be inaccurate; suggest standard phrasing.
Consider aligning with “OpenAPI Specification v2.0 (Swagger 2.0)”.-Introducing a new field, `schema.detail`, for customizing details for the route, following the standard of OpenAPI Schema V2 with auto-completion. +Introducing a new field, `schema.detail`, for customizing route details, following the OpenAPI Specification v2.0 (Swagger) with auto-completion.
118-121: Union types wording nits.
Minor clarity/consistency tweaks.-The previous version of Elysia sometimes had problems with distinct Union types, as Elysia tried to catch the response to create a full type reference for Eden. +The previous version of Elysia sometimes had problems with distinct union types, as Elysia tried to capture the response to create a full type reference for Eden. -This resulted in invalidation of possible types. +This sometimes invalidated the set of possible types.
123-124: Simplify “Union Response” sentence.
Streamline and lowercase “union types”.-Made possible by Union Type, returning multiple response statuses for `schema` is now available using `schema.response[statusCode]`. +Enabled by union types, multiple response statuses are now supported via `schema.response[statusCode]`.
164-167: Ecosystem bullets: minor wording tweaks.
Tighten phrasing and hyphenation.-- Eden with union-type inference for multiple responses +- Eden with union type inference for multiple responses -- New Elysia Apollo Plugin for Elysia +- New Apollo plugin for Elysia
169-172: Capitalize HTTP header and fix example formatting.
Use canonical “Content-Type” and parameter spacing.-- Body parser now parses `content-type` with extra attributes, e.g., `application/json;charset=utf-8` +- Body parser now parses the `Content-Type` header with extra attributes, e.g., `application/json; charset=utf-8`
176-179: Fix nested list indentation (markdownlint MD007).
Indent nested bullet with 2 spaces (not 4).- - To migrate, add `.request` to context to access `Request` + - To migrate, add `.request` to context to access `Request`
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/blog/elysia-02.md(4 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
docs/blog/elysia-02.md
178-178: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🔇 Additional comments (7)
docs/blog/elysia-02.md (7)
41-42: Good copy edit; reads clearly.
Improved flow and pluralization look correct.
47-51: Defers/lazy‑loading phrasing looks correct.
Grammar and clarity improvements are accurate.
72-72: Type inference sentence: LGTM.
Clear and correct.
96-107: Reference model section copy: LGTM.
Concise and consistent.
151-154: Union response validation and Swagger note: LGTM.
Accurate and clear.
156-159: Type inference performance note: LGTM.
Concise and informative.
181-188: Closing section edits: LGTM.
Reads naturally and consistently.
Summary by CodeRabbit