chore(demo): support api_key query param in vite example#3210
Conversation
Read the Stream API key from an `api_key` query param (falling back to VITE_STREAM_API_KEY), mirroring the existing `token` handling. Derive the user id from a provided `token` so `?api_key=β¦&token=β¦` works without a separate `user_id`, and parse tokens defensively so a malformed value falls through instead of throwing during render.
|
Size Change: +3 B (0%) Total Size: 656 kB π¦ View Changed
βΉοΈ View Unchanged
|
Codecov Reportβ
All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3210 +/- ##
=======================================
Coverage 83.84% 83.84%
=======================================
Files 439 439
Lines 13212 13212
Branches 4286 4286
=======================================
Hits 11077 11077
Misses 2135 2135 β View full report in Codecov by Harness. π New features to boost your workflow:
|
|
No actionable comments were generated in the recent review. π βΉοΈ Recent review infoβοΈ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: π Files selected for processing (1)
π WalkthroughWalkthroughThe Vite example app now safely handles token parsing and supports dynamic API key configuration. A new ChangesToken Parsing and API Key Configuration
Estimated code review effortπ― 2 (Simple) | β±οΈ ~8 minutes Suggested reviewers
Poem
π₯ Pre-merge checks | β 5β Passed checks (5 passed)
βοΈ Tip: You can configure your own custom pre-merge checks in the settings. β¨ Finishing Touchesπ Generate docstrings
π§ͺ 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 |
|
π This PR is included in version 14.4.0 π The release is available on: Your semantic-release bot π¦π |
π― Goal
The vite example could only take the Stream API key from the
VITE_STREAM_API_KEYenv var, while the usertokenwas already overridable via a query param. This makes it awkward to point the running example at a different Stream app without editing.envand restarting. This lets you pass?api_key=β¦(and combine it with?token=β¦) directly in the URL, matching howtokenalready works.π Implementation details
apiKeynow reads from theapi_keyquery param first, falling back toVITE_STREAM_API_KEYβ mirroring the existingtokenresolution.userIdnow derives from the providedtoken(viaparseUserIdFromToken) when present, slotted just below the explicituser_idquery param and above the env/localStorage/random fallbacks. This makes?api_key=β¦&token=β¦self-sufficient: previously the pronto token generator was only skipped when the resolveduserIdmatched the token's embeddeduser_id, so omittinguser_idsilently fell back to pronto with the wrong environment/app.parseUserIdFromTokennow returnsundefinedinstead of throwing on a malformed/empty token, since it now runs during render; this also hardens the existingtokenProvidercall site.User-id precedence:
?user_id=β token-derived βVITE_USER_IDβlocalStorageβ random. The explicituser_idparam still wins, preserving the "connect as someone else, regenerate via pronto" path.π¨ UI Changes
No visual changes β this only affects how the example app sources its credentials. Verified by driving the running example with Playwright:
?api_key=test_key_AAA&token=<jwt for "bob">β Stream WS connects withapi_key=test_key_AAAanduser_id=bob; pronto skipped.?api_key=test_key_BBB(no token) β prontocreate-tokencalled (fallback intact).?api_key=xzwhhgtazy6h(public key) β real connection succeeds, chat UI renders, zero console errors.Summary by CodeRabbit