Skip to content

docs: update right colored diffs #596

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

DaxServer
Copy link
Contributor

@DaxServer DaxServer commented Aug 8, 2025

Follows up #595

Summary by CodeRabbit

  • Documentation
    • Improved inline code comments and annotations for better clarity in the tutorial.
    • Enhanced formatting for increased readability.
    • Removed an unused import in the OpenTelemetry plugin example.
    • No changes to application behavior or functionality.

Copy link

coderabbitai bot commented Aug 8, 2025

Walkthrough

This update introduces inline annotation comments and minor formatting tweaks within a documentation tutorial file. The changes focus exclusively on improving code readability and annotation consistency without modifying any logic, structure, or behavior of the documented code examples.

Changes

Cohort / File(s) Change Summary
Documentation Inline Comments & Formatting
docs/tutorial.md
Added inline annotation comments, adjusted comment placement, and removed some empty lines for improved readability. Removed an unused import t from elysia in the OpenTelemetry example. No functional or structural code changes.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

A hop and a skip through docs I go,
Adding comments to help your knowledge grow.
No code was harmed, no logic did bend,
Just clearer notes from start to end.
With every line, a carrot of light—
Happy coding, and may your docs stay bright! 🥕

✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a 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

🔭 Outside diff range comments (1)
docs/tutorial.md (1)

1494-1496: Fix syntax and diff consistency in PATCH example

There’s a syntax error and an unannotated addition:

  • Extra closing parenthesis at the end of the note.update return.
  • The new body: 'memo' line isn’t marked as an addition, which breaks “right-colored” diff consistency in this block.

Apply this patch:

-        ({ note, params: { index }, body: { data }, status }) => { // [!code --]
-            if (index in note.data) return note.update(index, data) // [!code --]
-        ({ note, params: { index }, body: { data }, status, username }) => { // [!code ++]
-        	if (index in note.data) // [!code ++]
-         		return note.update(index, { data, author: username })) // [!code ++]
+        ({ note, params: { index }, body: { data }, status }) => { // [!code --]
+            if (index in note.data) return note.update(index, data) // [!code --]
+        ({ note, params: { index }, body: { data }, status, username }) => { // [!code ++]
+        	if (index in note.data) // [!code ++]
+         		return note.update(index, { data, author: username }) // [!code ++]
@@
-            body: 'memo'
+            body: 'memo' // [!code ++]

Also, consider removing the old handler entirely in this snippet to avoid confusion, relying solely on the [!code --]/[!code ++] annotations to communicate the change.

Also applies to: 1500-1504

🧹 Nitpick comments (2)
docs/tutorial.md (2)

1703-1712: Nit: unused import in observability example

t isn’t used in this block.

-import { Elysia, t } from 'elysia'
+import { Elysia } from 'elysia'

24-24: Minor grammar/wording fixes to polish the doc

  • Line 24: “Elysia feature” → “Elysia features”
  • Line 30: “From other framework?” → “From other frameworks?”
  • Line 77: “support Web Standard API” → “support the Web Standard API”
  • Line 108: “barebone project” → “bare-bones project”
  • Line 118: “Elysia use Bun” → “Elysia uses Bun”
  • Line 157: “both value and function” → “both values and functions”
  • Line 159: “use function to access” → “use a function to access”
  • Line 1311: “encapsulate lifecycle” → “encapsulates lifecycle”
  • Line 1612: “We use use” → “We use”
  • Line 2370: “And- that’s it” → “And that’s it”
  • Line 2374: “You could to take a step further” → “You could take it a step further”

Happy to open a quick follow-up PR with these copyedits if desired.

Also applies to: 30-30, 77-77, 108-108, 118-118, 157-157, 159-159, 1311-1311, 1612-1612, 2370-2370, 2374-2374

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7e67a56 and 8ea5e17.

📒 Files selected for processing (1)
  • docs/tutorial.md (15 hunks)
🔇 Additional comments (24)
docs/tutorial.md (24)

131-133: Route example enhancement is correct

Adds a second GET route to demonstrate simple value responses. Looks good.


150-155: Diff annotations for method and handler changes are consistent

  • GET → POST swap is properly marked.
  • Handler updated to use Context.path is correctly highlighted.

Also applies to: 162-169


190-194: Swagger plugin usage is correctly introduced

Applying .use(swagger()) before routes matches best practices and later references.


216-224: Decorator example reads cleanly

Introducing Note and injecting via decorate is accurate and consistent with later usage.


253-255: Path param snippet is fine (TS warning addressed later)

Defines :index cleanly; later “Validation” section resolves the typing warning.

Ensure the TS playground blocks (twoslash) show the expected hint for untyped params, so readers see the value of the follow-up validation step.


274-296: Validation with t.Object is introduced correctly

params: t.Object({ index: t.Number() }) and importing t are correct and align with later guard usage.


345-347: 404 via status helper is demonstrated properly

Clear, minimal example of returning a 404 when the index is missing.


375-377: Custom 404 message example is correct

Good follow-up to show a custom message variant.


427-450: Plugin extraction in index.ts is coherent

  • Importing note plugin and removing the inline Note routes are consistently annotated.
  • Ensures the main app is decluttered.

472-485: CRUD additions are technically sound and easy to follow

  • Methods add, remove, update on Note are idiomatic for the tutorial.
  • Route validations for body/params match their handlers.

Also applies to: 490-494, 506-518, 519-534


550-553: Prefix grouping is a good simplification

Switching to new Elysia({ prefix: '/note' }) and updating paths to relative is consistent.


620-626: Guard consolidation is correct

Centralizes params validation and removes redundancy in per-route schemas. Annotations accurately show removals.

Also applies to: 632-637, 647-652, 662-666


690-695: Lifecycle onTransform is placed correctly

Hook is added before routes; logs are minimal and illustrative.


749-818: Auth: user module scaffolding looks good

  • state stores and cookie schema are reasonable for a tutorial.
  • Sign-up/sign-in flows are clear; diff annotations consistent.

For readers running Bun: confirm Bun.password.hash/verify work as-is for the example versions used in docs.


859-880: Reference models are introduced well

signIn, session, and optionalSession models reduce duplication effectively.


1023-1056: Sign-out and profile routes are consistent with earlier models

  • Uses modeled cookies correctly.
  • token.remove() is a good demonstration.

1074-1107: Service/plugin deduplication is accurate

  • Naming the service plugin prevents duplicate registration.
  • Properly removes duplicate state/model from user once userService is used.

Also applies to: 1109-1142


1189-1217: Macro isSignIn is correctly structured

Returning beforeHandle via macro is a neat pattern; annotations clearly mark new lines.


1228-1250: Macro usage reads well

Using isSignIn: true lets you remove imperative checks from the handler. Good example.


1268-1278: Resolve pattern is demonstrated clearly

Defining username via .resolve after a guard is coherent and matches the narrative.


1328-1334: Scoped lifecycle usage is correct

Both inline as: 'scoped' and chained .as('scoped') are shown; nice to include both.

Also applies to: 1364-1364


1410-1416: Authorization refactor is solid (Memo schema + typed updates)

  • Introducing memo and using t.Omit for body is great.
  • Updating Note methods to Memo/Partial<Memo> is consistent.
  • PUT now attaches author via username; good.

Also applies to: 1419-1444, 1450-1451, 1464-1469


1547-1567: Final authorized note controller is coherent

  • .use(userService) then .use(getUserId) before protected routes is correct.
  • Validations and macro usage align with previous sections.

Also applies to: 1569-1601


1626-1631: onError examples are well placed and accurate

Showing both “ignore NOT_FOUND” and “custom 404 body” variations is helpful.

Also applies to: 1660-1663

Copy link

@coderabbitai coderabbitai bot left a 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

🔭 Outside diff range comments (1)
docs/tutorial.md (1)

1478-1481: Syntax error: extra closing parenthesis in patch handler

There’s an extra “)” after note.update(...), which will break the example.

-        ({ note, params: { index }, body: { data }, status, username }) => { // [!code ++]
-        	if (index in note.data) // [!code ++]
-         		return note.update(index, { data, author: username })) // [!code ++]
+        ({ note, params: { index }, body: { data }, status, username }) => { // [!code ++]
+            if (index in note.data) // [!code ++]
+                return note.update(index, { data, author: username }) // [!code ++]
🧹 Nitpick comments (4)
docs/tutorial.md (4)

690-695: Be careful logging request bodies and params

Logging body and params verbatim can leak sensitive info in real apps. Consider redacting or filtering fields (e.g., passwords) before logging.

-    .onTransform(function log({ body, params, path, request: { method } }) {
-        console.log(`${method} ${path}`, {
-            body,
-            params
-        })
-    })
+    .onTransform(function log({ body, params, path, request: { method } }) {
+        const redactedBody = body && typeof body === 'object'
+          ? { ...body, password: body.password ? '<redacted>' : body.password }
+          : body
+        console.log(`${method} ${path}`, {
+            body: redactedBody,
+            params
+        })
+    })

749-820: Auth examples are clear; minor security note on cookie options

Examples use hashing and cookies correctly for a tutorial. For production, ensure cookies are set httpOnly, secure, and with SameSite to mitigate CSRF; these are set when issuing cookies, not in the t.Cookie model schema.


796-803: Session token generation is weak for production

Using a 32-bit random number as a session token is guessable at scale. Prefer a cryptographically strong, high-entropy identifier (e.g., UUIDv4 or 128-bit random bytes). This will require changing the cookie and session map to string keys.

-            const key = crypto.getRandomValues(new Uint32Array(1))[0]
-            session[key] = username
-            token.value = key
+            const key = crypto.randomUUID()
+            session[key] = username
+            token.value = key

And update models/store accordingly:

-    session: {} as Record<number, string>
+    session: {} as Record<string, string>
-    token: t.Number()
+    token: t.String()

1023-1036: Use POST for sign-out to avoid unsafe GET side-effects

GET should be safe/idempotent; logging out mutates state and is susceptible to CSRF. Prefer POST here.

-    .get(
+    .post(
         '/sign-out',
         ({ cookie: { token } }) => {
             token.remove()
             return {
                 success: true,
                 message: 'Signed out'
             }
         },
         {
             cookie: 'optionalSession'
         }
     )
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8ea5e17 and da25393.

📒 Files selected for processing (1)
  • docs/tutorial.md (23 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
docs/tutorial.md

1453-1453: Hard tabs
Column: 7

(MD010, no-hard-tabs)

🔇 Additional comments (13)
docs/tutorial.md (13)

131-133: Right-diff callouts moved inline — looks good

Placing [!code ++] at EOL inside TS comments is correct for VitePress callouts and improves readability.


189-194: Swagger plugin callout placement — good

Inline callout reads clearly; no functional change to the example.


216-224: Decorate example reads cleanly

Inline callouts on class and decorator lines are consistent and readable.


253-256: Path parameter example — callouts OK

EOL callouts are consistent. Example compiles conceptually as-is.


290-296: Validation block callouts — OK

Good placement on opening/closing braces and schema fields.


345-347: Status handling callouts — OK

Adding status() call is clearly marked and correct in context.


472-485: CRUD additions — examples look correct

Callout placement is consistent across put/delete/patch handlers and schemas.

Also applies to: 490-495, 506-518, 519-534


550-553: Grouping with prefix — good

Switching to a prefixed instance and updating routes improves clarity.


620-626: Guard extraction — nice reduction of duplication

Moving params validation into guard and removing per-route schemas is the right call.

Also applies to: 631-637, 647-653, 662-666


1395-1401: Fix hard tabs flagged by markdownlint (MD010) in this block

Replace hard tabs with spaces for consistency and to satisfy MD010. Example:

-const memo = t.Object({
-	data: t.String(), // [!code ++]
-	author: t.String() // [!code ++]
-}) // [!code ++]
+const memo = t.Object({
+    data: t.String(), // [!code ++]
+    author: t.String() // [!code ++]
+}) // [!code ++]

1451-1454: Fix hard tab indentation (MD010) here as well

The linter reports a tab at Line 1453, replace tabs with spaces in this small block.

-      { // [!code ++]
-       body: 'memo' // [!code ++]
-       } // [!code ++]
+      { // [!code ++]
+        body: 'memo' // [!code ++]
+      } // [!code ++]

1488-1489: Body schema alias usage — looks good

Switching to the named 'memo' model keeps runtime/type-level in sync; nice touch.


1686-1695: OpenTelemetry example — callouts and order look correct

Plugin order (opentelemetry before swagger) and EOL callouts are consistent.

Copy link

@coderabbitai coderabbitai bot left a 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 (1)
docs/tutorial.md (1)

1451-1454: Replace hard tabs with spaces

The code blocks at these lines contain hard tabs, tripping markdown-lint rule MD010. Switch to spaces for consistency with the rest of the doc and to satisfy lint.

Also applies to: 1480-1483

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between da25393 and 10e47cf.

📒 Files selected for processing (1)
  • docs/tutorial.md (24 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
docs/tutorial.md

1453-1453: Hard tabs
Column: 7

(MD010, no-hard-tabs)


1480-1480: Hard tabs
Column: 10

(MD010, no-hard-tabs)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant