New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: Better support for types in where clauses #8116
Comments
It's an interesting proposal for DX improvement. It would have to use a similar mechanism as UpdateData to handle nested property names. I'm not sure what mechanism it could use to also validate the data type for given properties. FWIW, if you use the code in your sandbox, you might want to constrain the path based on the DbModelType instead of the AppModelType, since the DbModelType represents the shape of the data stored in your DB. |
Good to know! In my case Db and App models are identical so I did not notice the discrepancy. Regarding nested property names I wrote a another type to help me:
This flattens nested keys out nicely for my use case. I've been using it just a short while but it's actually a really nice quality of life improvement. |
Operating System
MacOS Monterey 12.5.1
Browser Version
123.0.6312.87
Firebase SDK Version
^10.8.0
Firebase SDK Product:
Firestore
Describe your project's tooling
React app build with Vite
Describe the problem
Hi,
I'm using Firestore with converters to get typescript support. It works pretty well, but I've noticed that it could become even more powerful in the DX department and even help fix a source of runtime errors.
I think it would be awesome if we could have checked keys when doing
where
clauses in aquery
. I have multiple times in app-development accidentally used a wrong key and gotten frustrated with not understanding various resulting errors.I've created a little sandbox that actually implements this check. To do this, I've resorted to hacking the exported types. I also do not support the full scope of features, such as passing in
FieldValue
s and supporting other query types.https://codesandbox.io/p/sandbox/firestore-where-types-rl9gx8?file=%2Findex.ts
I also tried to create a fork that would create these types upstream. Since the public api is created based on some automagic inference of the written code, I did not really have much luck. Hopefully somebody internal with a better grip on the build system and type situation can remedy this?
Steps and code to reproduce issue
Open up the codesandbox to see an example of where, and how, I think the types could be improved
The text was updated successfully, but these errors were encountered: