Jon Staab de5695339d 1. throttle (line 1146-1174)
Before: Used recursive setTimeout calls via unpause, creating nested closures and multiple timer contexts.

After:
- Tracks a single timeoutId to manage timer lifecycle
- Eliminates nested closure creation
- Cleaner timer chain when calls are pending

2. batch (line 1204-1227)

Before: Used throttle internally, inheriting its timer overhead.

After:
- Direct timer management without the throttle wrapper
- Single timeoutId tracked explicitly
- Maintains the same semantics (first item processed immediately, rest batched)

3. batcher (line 1235-1259)

Before:
- Created new timer every time queue went from empty to non-empty
- Had unnecessary async in forEach and await r when r was already type U

After:
- Tracks timeoutId to prevent duplicate timer creation
- Only creates timer when queue is truly empty
- Removed unnecessary async/await in result handling
- More efficient error handling (rejects all items at once if length mismatch)

Performance Benefits:

These changes should significantly reduce timer overhead by:
- Fewer timer objects: Only one active timer per throttled/batched function instead of chains
- Less garbage collection: Fewer closure allocations and intermediate objects
- Better memory usage: Explicit timer ID tracking instead of implicit state in closures
2025-11-14 15:29:03 -08:00
2025-04-02 10:15:49 -07:00
2025-10-13 15:08:42 -07:00
2025-11-12 11:06:13 -08:00
2025-11-14 15:29:03 -08:00
2025-09-30 15:55:18 -07:00
2023-09-20 13:52:45 -07:00
2025-06-11 15:12:12 -07:00
2025-04-02 10:15:49 -07:00
2025-04-08 15:11:15 -07:00
2025-02-28 15:30:57 -08:00
2025-04-09 11:58:29 -07:00
2025-04-09 11:58:29 -07:00
2023-03-25 11:58:52 -05:00
2025-11-11 14:06:34 -08:00
2025-04-02 10:15:49 -07:00
2025-04-02 10:15:49 -07:00
2025-04-02 10:15:49 -07:00
2025-04-08 15:11:15 -07:00
2025-10-01 16:59:16 -07:00
2025-04-09 13:47:59 -07:00

Welshman

A nostr toolkit focused on creating highly a configurable client system, extracted from the Coracle nostr client.

Linking

If you're developing an application which requires changes to welshman, you'll need to use npm link to link the two. This is an annoying process, and is only supported if using npm.

  • Clone welshman and the repository that depends on it
  • Within each package directory in welshman, run npm link
  • Within your application directory, link all welshman dependencies simultaneously (or else only one will get linked. A command that does this is: rm -rf node_modules; npm i; cat package.json|js '.dependencies|keys[]'|grep welshman|xargs npm link.

If you run npm install in your application directory, you'll need to repeat the final step above. Finally, if you're using the editor module, you may run into some dependency version conflicts. I recommend editing the command above to exclude the editor.

S
Description
No description provided
Readme MIT 4.3 MiB
Languages
TypeScript 99.4%
CSS 0.3%
JavaScript 0.3%