-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
feat: add signal
to EIP1193RequestOptions
#3840
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
⚠️ No Changeset found
Latest commit: 63a7eca
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
edd485b
to
226d74f
Compare
226d74f
to
eb84560
Compare
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.
Excited for this! Some random code style feedback.
Co-authored-by: tmm <tom@meagher.co>
Excited for this! Some random code style feedback.
thanks—applied
Happy to continue with the other Actions too.
I took an initial stab at it. It's ok but having done it this way it might more sense to figure out all the changes required for an action and then go through each one and apply all the changes:
- accept requestOptions
- make sure RequestErrorType is included in the error type
- update the docs page to include requestOptions
a couple others that I'm not sure about but seemed useful:
- add a test case to the actions tests for requestOptions. wasn't sure if adding to each action is worth it or too redudant
- explicit handling of request errors in catches. for actions that have extra handling that wrap errors in a specific error type would it make sense to check for AbortError or generally for non-base errors and instead immediately rethrow unwrapped?
MKRhere
commented
Sep 9, 2025
Not to bother, but could we update this branch from main and avoid it going stale? I've been watching this PR eagerly :)
129b947
to
9ad3509
Compare
d78cf00
to
b31cf2a
Compare
This PR address #1701. If the approach looks good I'll extrapolate to the rest of the actions where this makes sense.