Closed henrymoulton closed 4 years ago
@henrymoulton thanks for the report. I'm unable to reproduce. Can you please make sure that your Fireward version is 1.2.3
by running fireward --version
?
Was my fault, was running an old version in a different shell!
@henrymoulton no problem. At this stage, it's much better for the project to have users reporting false positives than not at all.
Thanks, I wondered if you had any thoughts on statically typing the firestore().collection
and .doc()
references based on fireward types. At the moment I've created some string enums separately but it's something in the back of my mind when doing data fetching. GraphQL knows which queries are possible via a schema... do you think something similar is possible with Firestore?
I've tried building elaborate systems for this in the past, but they all turned out to be overly complex and not very useful. Maybe 2019 improvements in TS would have made it much easier, but I am too skeptical to explore.
The approach I would recommend today is more manual and straight forward. You can create a client object, similar to one you might make for a regular REST API, and it would provide typed results. Something like this:
export const firestoreClient = {
watchUser: (userId: string, callback: (user?: User)=>void) =>
firestore.collection('users').doc(userId).onSnapshot(doc=>callback(doc.data()))
}
Hi, thanks for the release of string literals!
When my type is:
My terminal output is:
My rules generated are:
The idea here is I want to be able to specify types I can share across documents where data is duplicated, which is quite common in Firestore, in this example
UserDataForAdminDoc
is readable and writable by Admins, and any change is copied over toUserStatusDoc
with a Firebase function, allowing the user to be able to read their status, but not change it.