GIF API.

I'm back working on a web-based client now that this side-quest is released. 👇 Holy feedback cycle, Batman! Native is cool and all, but compiling sucks for UI iteration.

Two Nostr signers at the same time?

We have the Google as well: https://gitworkshop.dev//pomegranate

ditto.pub seems to have an infinite loop bug in `useAuthors`. I noticed because my CPU fan was spinning up when nothing much else was running. I profiled it and asked my clanker to figure it out: ================== **Ditto appears to have a continuous React → database → React feedback loop in its `useAuthors` hook.** That’s the main repeated work in this profile. Across the **9.38-second capture**: | Work | Measured activity | |---|---:| | Ditto’s main page thread | **8.10 seconds of CPU — 86% of one core** | | Timer callbacks traced to `useAuthors` cache updates | **2,461 — about 262/second** | | Time inside those callbacks, including resulting work | **6.61 seconds** | | IndexedDB `success` events | **2,461** | The load stays high throughout the capture, so this isn’t just a brief startup spike. I fetched the exact JavaScript bundle named in your profile. The [deployed `useAuthors` code](https://ditto.pub/assets/useAuthors-jBNN03G9.js) does this: 1. Each render creates a **fresh array** of sorted, unique author IDs. 2. That array is in a `useEffect` dependency list. Its identity changes every render, even when the authors haven’t changed. 3. The effect queries IndexedDB for those authors’ profiles. 4. It writes a **new `Map`** into the `["authors", …]` query cache, even when the profiles are unchanged. 5. The cache update causes another render, restarting the cycle. The profile directly connects those cache writes to the query library’s zero-delay timer scheduler, followed by substantial React rendering work. Its roughly matching timer and database event counts strongly support this diagnosis. The hook’s five-minute `staleTime` doesn’t prevent this: the repeated reads happen in a separate effect. **The developer fix:** make that effect depend on the *contents* of the author list rather than a newly allocated array, and preserve the existing cached `Map` when nothing changed. Both would break the unnecessary update cycle.

Kind 1111 replies to kind 1 notes*

Damus and (maybe) Primal don’t render kind 1111 replies, so makes sense.

Test reply reply

Test reply

Test note