-
Notifications
You must be signed in to change notification settings - Fork 455
docs(tutorial): show string status names in lifecycle examples #739
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
|
Warning Rate limit exceeded@braden-w has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 0 minutes and 3 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughDocumentation updates across three tutorial files that enhance status code usage examples. Changes include fixing syntax errors (trailing apostrophes), adding string-based status name examples alongside numeric variants, and providing guidance about TypeScript autocompletion support for HTTP status strings. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
docs/tutorial/getting-started/life-cycle/index.md(2 hunks)docs/tutorial/getting-started/status-and-headers/index.md(1 hunks)docs/tutorial/patterns/error-handling/index.md(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
docs/tutorial/getting-started/status-and-headers/index.md
64-64: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/tutorial/getting-started/life-cycle/index.md
65-65: Hard tabs
Column: 1
(MD010, no-hard-tabs)
66-66: Hard tabs
Column: 1
(MD010, no-hard-tabs)
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (2)
docs/tutorial/patterns/error-handling/index.md (1)
48-48: Minor syntax polish to the error response message.Using plain apostrophes inside double-quoted strings is cleaner than escaping. This change improves readability without affecting functionality.
docs/tutorial/getting-started/life-cycle/index.md (1)
65-152: Approve content improvements across lifecycle documentation.The additions clearly demonstrate string status names as alternatives to numeric codes. The example at line 152 (
status("Unauthorized")) is particularly effective for showing real-world usage that aligns with HTTP semantics. This reinforces the feature well across the tutorial.
| Here we use `status(418)` which is the "I'm a teapot" status code. You can also use the string name directly: `status("I'm a teapot")`. See <DocLink href="/tutorial/getting-started/status-and-headers">Status and Headers</DocLink> for more on using status codes. | ||
|
|
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.
Fix hard tab indentation and improve documentation formatting.
The new explanation of string status names is clear and helpful. However, lines 65–66 use hard tabs for indentation, which violates the markdown linting rule (MD010). Replace hard tabs with spaces.
-Here we use `status(418)` which is the "I'm a teapot" status code. You can also use the string name directly: `status("I'm a teapot")`. See <DocLink href="/tutorial/getting-started/status-and-headers">Status and Headers</DocLink> for more on using status codes.
+Here we use `status(418)` which is the "I'm a teapot" status code. You can also use the string name directly: `status("I'm a teapot")`. See <DocLink href="/tutorial/getting-started/status-and-headers">Status and Headers</DocLink> for more on using status codes.(Replace leading hard tabs with spaces to maintain consistency with the rest of the file.)
📝 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.
| Here we use `status(418)` which is the "I'm a teapot" status code. You can also use the string name directly: `status("I'm a teapot")`. See <DocLink href="/tutorial/getting-started/status-and-headers">Status and Headers</DocLink> for more on using status codes. | |
| Here we use `status(418)` which is the "I'm a teapot" status code. You can also use the string name directly: `status("I'm a teapot")`. See <DocLink href="/tutorial/getting-started/status-and-headers">Status and Headers</DocLink> for more on using status codes. | |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
65-65: Hard tabs
Column: 1
(MD010, no-hard-tabs)
66-66: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/tutorial/getting-started/life-cycle/index.md around lines 65 to 66, the
two lines introducing the `status(418)` example use leading hard tabs which
violate MD010; replace those leading hard tab characters with spaces to match
the file's existing indentation style (use the same number of spaces used
elsewhere in this document) and ensure spacing/formatting remains consistent,
then re-run the markdown linter to confirm the MD010 warning is resolved.
| new Elysia() | ||
| .onBeforeHandle(({ query: { name }, status }) => { | ||
| if(!name) return status(401) | ||
| if(!name) return status("Unauthorized") |
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.
Fix hard tab indentation in assignment example.
The change from status(401) to status("Unauthorized") is a great improvement that reinforces the string status name feature. However, line 152 uses a hard tab for indentation, which violates the markdown linting rule (MD010). Replace the hard tab with spaces.
- if(!name) return status("Unauthorized")
+ if(!name) return status("Unauthorized")(Replace leading hard tabs with spaces to maintain consistency with the rest of the file.)
📝 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.
| if(!name) return status("Unauthorized") | |
| if(!name) return status("Unauthorized") |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/tutorial/getting-started/life-cycle/index.md around line 152, the line
"if(!name) return status("Unauthorized")" uses a hard tab for indentation which
violates MD010; replace the leading hard tab with the same number of spaces used
elsewhere in this file (convert the tab to spaces) so indentation is consistent
with the rest of the document and markdown linting passes.
| The status code can be a number or a string status name. Both of these are equivalent: | ||
|
|
||
| ```typescript | ||
| status(418, "I'm a teapot") | ||
| status("I'm a teapot", "I'm a teapot") | ||
| ``` | ||
|
|
||
| String status names provide TypeScript autocompletion for all valid HTTP statuses. | ||
|
|
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.
Fix hard tab indentation on line 64.
The new documentation section on string status names is clear and helpful. However, line 64 uses a hard tab for indentation, which violates the markdown linting rule (MD010). Replace the hard tab with spaces to maintain consistency with the rest of the file.
String status names provide TypeScript autocompletion for all valid HTTP statuses.
-
+
See <DocLink href="/essential/handler#status">Status</DocLink>.(Note: The diff shows replacing the hard-tabbed empty line with a space-based one. Ensure all indentation on line 64 uses spaces, not tabs.)
Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
64-64: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/tutorial/getting-started/status-and-headers/index.md around lines 56 to
64, line 64 uses a hard tab for indentation which violates MD010; replace the
hard tab character(s) on that line with equivalent spaces so the empty/indented
line uses space-based indentation consistent with the rest of the file, and
ensure no other tabs remain on that line.
Add inline comments showing string alternatives:
- status(418) // or status("I'm a teapot")
- status(401) // or status("Unauthorized")
Also add explanatory note that status() accepts both formats.
- Remove '// or' comments in favor of clearer explanatory text
- Add note explaining 418 = 'I'm a teapot' with link to status tutorial
- Use status("Unauthorized") for auth example (clearer than 401)
- Keep status(418) for teapot examples
30b6078 to
a41ff8e
Compare
This improves discoverability of string status names by adding inline comments to lifecycle examples in the getting started tutorial. When developers work through the tutorial, they'll now see that status accepts both numeric codes and descriptive string names like 'Not Found' or 'Internal Server Error', making the API more intuitive without requiring them to search through reference documentation to discover this feature.
This is part of a broader effort to surface string status name usage throughout the documentation. Related PRs #740, #741, #742, #743, #744, and #745 apply similar improvements to other sections of the docs, ensuring developers encounter this helpful pattern consistently as they learn the framework.