- From: Evan Stade <notifications@github.com>
- Date: Wed, 07 May 2025 14:45:52 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/130/2860465489@github.com>
evanstade left a comment (w3c/IndexedDB#130) My initial reaction was that this feature detection problem must have been solved elsewhere. But actually, it seems like it's just [been a problem forever](https://github.com/whatwg/webidl/issues/107). I think I would go with #1 --- hopefully the con is a non-issue, i.e. browser vendors will be allocating resources to add `getAllRecords` support along with reverse `getAll`. This doesn't solve the hypothetical future dilemma, but it does follow the standard approach of using an optional dictionary for options, and doesn't get us any *farther* from solving the future feature detection problem, which is apparently hard. Another option would be adding a `getAllAdvanced` instead of overloading `getAll`, which also only solves our problem this one time, and is generally sort of gross? But at least doesn't force `getAllRecords` to be implemented. (I don't know if a suffix like "Advanced", a la the Windows idiom of "Ex", is officially banned; I'm sure it's not recommended if there are better options. But this filler word could be anything really, such as "Options".) -- Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/130#issuecomment-2860465489 You are receiving this because you are subscribed to this thread. Message ID: <w3c/IndexedDB/issues/130/2860465489@github.com>
Received on Wednesday, 7 May 2025 21:45:57 UTC