Allow reactive options in signal based adapters
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- angular, react, typescript
- Domain
- frontend
Research direction
Start by comparing the linked rate-limiter entry points in packages/react-pacer/src/rate-limiter/useRateLimiter.ts, packages/solid-pacer/src/rate-limiter/createRateLimiter.ts, and packages/angular-pacer/src/rate-limiter/injectRateLimiter.ts. Trace how React updates options and determine the corresponding reactive behavior needed for the signal-based adapters; done means changing options works for Solid and Angular use cases described in the issue.
Written by the indexing model from the issue text.
Description
TanStack Pacer version
0.19.0
Framework/Library version
Solid, Angular
Describe the bug and the steps to reproduce it
In the React adapter, options for pacer APIs are reactive, and update when the given options object change.
But in Solid and Angular, the APIs accept only a object as an argument, and since those functions only run once, there is no way the adapter can update the options by itself like React. In other libraries, like query and hotkeys, options allow (or are given only by) a function in the signal based adapters (Solid, Angular, etc).
This can be annoying in some cases in Angular, since input signals can't be read on initialization, so there would be no simple way to use any of pacer APIs when the options depend on the component inputs.
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
No repo since this is a behaviour issue. Here are links to the code for rate limiter, where react updates the options but the other adapters do not: React, Solid, Angular. Note that only React calls setOptions.
Screenshots or Videos (Optional)
No response
Do you intend to try to help solve this bug with your own PR?
Maybe, I'll investigate and start debugging
Terms & Code of Conduct
- I agree to follow this project's Code of Conduct
- I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
- Dominant language
- TypeScript
- Stars
- 776
- Forks
- 67
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 8
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from TanStack/pacer
-
replace deprecated Vitest spy assertion aliasesPossibly taken @2yunseong claimed this 18 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 66/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
Maintainers usually reply within 1 day
Similar issues
-
Show the error reference on the error pagePossibly taken A pull request linked to this issue is open or already merged. Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
tomjn/coilbox-hub#454 ·
Maintainers usually reply within 1 day
-
frontend
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
icssc/peterportal-client#1224 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
api: spanner
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
googleapis/google-cloud-node#9513 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
Maintainers usually reply within 1 day