Closed tlserver closed 7 months ago
The id
property is needed for VueFire to apply certain optimizations, as noted in documentation. You will need to name your property something else. Adding a dot in front makes it annoying to use object['.id']
in v-for loops and db writes that's why it wasn't used.
Regarding other properties, that same page also explains how to add custom data to the document. Adding everything by default would bloat the data, especially in SSR.
Yes, it may be annoying, but it at least does not break things which is more importance.
You will need to name your property something else.
If this issue is not planned to be fixed, this should be stated in document with highlighting.
But I think, Vuefire should use .id
internally, user can still define a custom converter to add a id
field back to the object and keep v-for clean. So that, .id
is not annoying any more. BUT, now we have NO WAY to get the real id field in document even adding custom converter since vuefire is not working properly with a "wrong" id.
Since useDocument
I really hope this issue be fixed, this commit may help.
For the moment, id
is a very practical default and will likely stay that way. What is actionable in the near future is allowing overwriting the global type so one can customize the global converters while things being typed and of course document it with some practical examples like adding the ref like you propose
Reproduction
Please see step 2
Steps to reproduce the bug
id
such asconst firestore = getFirestore(); const docStm = useDocument(doc(firestore, 'AnyCol/AnyDoc')); watch(docStm, console.log, {immediate: true});
Expected behavior
id should be
123
Actual behavior
id is overrided to document ID (
AnyDoc
)Additional information
It is good for vuefire to provide access to document id but I think it should not use a normal field name![image](https://github.com/vuejs/vuefire/assets/8895426/abcf77fd-11d4-4101-9ace-ee4af53bc8f6)
id
, since it is a valid field name for firestore too. Use a special field name such as.id
can avoid conflict with document data. One constraint about the firestore document field name is 'not start with a dot(.
)'.Also, as suggested in #180, I think the following properties should be exposed to the vuefire data object as non-enumerable properties: