Skip to content
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

1529 convert realtime to use promises #1576

Draft
wants to merge 32 commits into
base: main
Choose a base branch
from

Conversation

lawrence-forooghian
Copy link
Collaborator

No description provided.

@github-actions github-actions bot temporarily deployed to staging/pull/1576/features January 16, 2024 11:43 Inactive
@github-actions github-actions bot temporarily deployed to staging/pull/1576/typedoc January 16, 2024 11:43 Inactive
@github-actions github-actions bot temporarily deployed to staging/pull/1576/bundle-report January 16, 2024 11:43 Inactive
@lawrence-forooghian lawrence-forooghian force-pushed the 1529-convert-realtime-to-use-promises branch from 012e586 to bbf32b6 Compare January 16, 2024 13:12
@lawrence-forooghian lawrence-forooghian force-pushed the remove-callbacks-part-1 branch 4 times, most recently from 14e1e5b to b429c13 Compare January 30, 2024 18:02
Base automatically changed from remove-callbacks-part-1 to integration/v2 January 31, 2024 12:11
When I added whenPromiseSettles in cd6c2d8, I didn’t realise that
TypeScript types the `catch` callback’s argument as `any`, which doesn’t
make much sense to me given that the argument of a `catch` clause is
typed as `unknown` (the latter seeming more appropriate).

So, make it explicit that we’re performing a type assertion on the
error.
The compiler knows that these are non-nullish, which will come in handy.
For consistency with our other callbacks.
The approach taken here is the same as that taken in 2001675, in order
to be able to emit both an error _and_ the response body.

Note that in the "just in case" handling of thrown errors I’ve just
typed the thrown error as `any` and not worried about the consequences
of doing so; we can figure out how to handle this properly and
consistently in #1617.
The type assertions masked quite a few inconsistencies, which I’ve
attempted to handle here.
We removed RequestCallback in 146ca71.
@lawrence-forooghian lawrence-forooghian changed the base branch from integration/v2 to 1533-remove-callbacks-from-http-code February 9, 2024 13:20
TODO remove this, since I removed it on the base branch too
TODO it’s a nuisance that we can’t access the event via promises, so
this is still using `once` with callbacks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant