id field value is override by vuefire about vuefire HOT 3 CLOSED

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.

from vuefire.

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() return VueFirestoreDocumentData, defining a global firestore converter does not make typescript happy when reading other field. Type casting or bypassing the TS rule every where is needed, it is annoying.
How about just add ref by default? If it is still too big to have a DocumentReference object, a full path string is still very useful for everyone.

I really hope this issue be fixed, this commit may help.

from vuefire.

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

from vuefire.