Repository navigation
add a .findOne() to query build to return the first item #182
Description
e.g. instead of:
const { data: users } = useLiveQuery(
(q) =>
q
.from({ usersCollection })
.where(`@usersCollection.id`, `=`, userId),
[userId]
)
const user = users[0]We could write:
const { data: user } = useLiveQuery(
(q) =>
q
.from({ usersCollection })
.where(`@usersCollection.id`, `=`, userId)
.findOne(),
[userId]
)
Activity
samwillis commentedon Jun 17, 2025
The query is materialised into a collection, we would need to find a way to not have a collection to make this work. Maybe it's a feature of the hook rather than the query?
We will also need a stable order, so it may require an orderBy.
Alternatively we do a one off query first to get the first item, then just subscribe to that.
Note that with a
orderByand alimit(1)you don't needusers[0], but it's still a collection.KyleAMathews commentedon Jun 17, 2025
Oh
limit(1)already turns it into an object instead of an array?KyleAMathews commentedon Jun 17, 2025
no it doesn't :-D
Yeah, the hook could just see that
findOneis on the query & return the first object.KyleAMathews commentedon Jun 17, 2025
Maybe default to ordering by the key if an explicit
orderByisn't added? I'd assume that the item that's found would change if the order changes so either people are explicit about the order, etc. or they're accepting things potentially moving around a bit.samwillis commentedon Jun 17, 2025
orderBy adds overhead... maybe we can just document that the user should provide a stable order if they expect more than one result. I can see
fineOnebeing mostly used for UI screens where there is only ever one result - a filter by PK.internally the query returns a
CompiledQueryobject, that has a.result- maybe when there is afineOnewe keep the internal collection, but.resultisresultCollection[0]rather thanresultCollection.It will need some jiggery pokery on the types of
useLiveQueryto ensure that when there is afineOneit not an array. Very doable.kevin-dp commentedon Jul 24, 2025
What's the status of this?
This issue #192 was related and got fixed by this PR: #155. Does that simplify the implementation of this feature?
KyleAMathews commentedon Jul 24, 2025
No one has looked further at it — if you want to take a crack at implementing it, it'd be a nice DX improvement for sure for people!
evanheckert commentedon Oct 9, 2025
Coming from Django, they have a few ways to get there.
Django
QuerySetmethods that return a single model instance:.get()- Retrieves exactly one object matching the query; raisesDoesNotExistif none,MultipleObjectsReturnedif more than one..first()- Returns the first object in the queryset, orNoneif empty..last()- Returns the last object in the queryset, orNoneif empty..earliest()- Returns the earliest object according to the model’sget_latest_byMeta option or a given field..latest()- Returns the latest object according to the model’sget_latest_byMeta option or a given field.latest()/earliest()for a given date field is accomplished bygroupBy()withmax()/min(), but that's just returning the latest date value, not the record that happens to be the latest/earliest. Also, I'd love to be able to use :groupBy()-->sortBy()-->first().evanheckert commentedon Oct 25, 2025
I noticed
findOne()is now mentioned in the docs, but typescript is not having it (just resolves tonever) in latest.{ "@electric-sql/client": "^1.1.0", "@electric-sql/react": "^1.0.15", ... "@tanstack/electric-db-collection": "^0.1.38", "@tanstack/query-core": "^5.90.5", "@tanstack/query-db-collection": "^0.2.36", "@tanstack/react-db": "^0.1.36", ... "zod": "^4.1.12" "react": "^19.2.0", "react-dom": "^19.2.0", "vite": "^7.1.12", ... "babel-plugin-react-compiler": "^1.0.0", "typescript": "^5.9.3", }Edit: I see it was actually in (#440 ). I'll need to see if I can put together a simple repro.
evanheckert commentedon Oct 27, 2025
New day, fresh start to typescript server, and it's working as intended! Can probably close this one @KyleAMathews
Edit: Turns out it worked sometimes but not when joins were present. In any case, being fixed in #749