docs: use string status names in examples #742
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 24 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 (2)
✨ Finishing touches🧪 Generate unit tests (beta)
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 |
braden-w
force-pushed
the
layer-6-string-names
branch
3 times, most recently
from
42998af to
8e0d1ce
Compare
- Convert status(418) to status("I'm a teapot") in validation tutorial
- Convert status(418) to status("I'm a teapot") in macro tutorial
- Convert status(401) to status("Unauthorized") in macro auth example
braden-w
force-pushed
the
layer-6-string-names
branch
from
8e0d1ce to
ff7acde
Compare
|
Superseded by #747 (conversions) |
1 participant
This PR updates the macro and validation tutorial examples to use string status names instead of numeric codes. The change makes the examples more readable and self-documenting: seeing
t.status('Bad Request')is clearer thant.status(400), especially for developers who haven't memorized HTTP status codes.I recognize this is a stylistic preference, and you may prefer numeric codes for consistency or other reasons. If so, feel free to reject this PR; I completely understand.
This change is part of a broader effort across PRs #739-#741 and #743-#745 to improve the visibility and usage of string status names throughout the documentation. The goal is to make it easier for developers to discover and use this feature, since many may not realize Elysia supports both numeric and string status codes.