Avoid storing reserved fields in document

[AlexanderArvidsson]

Creating or updating documents adds the id field to the actual document.
There are certain reserved fields in Firestore that should not exist within the document.

The package @nandorojo/swr-firestore will warn you when it finds documents that contain one of the following reserved fields: exists, id, hasPendingWrites.

[use-collection] warning: Your document,  <id> is using one of the following reserved fields: [exists, id, hasPendingWrites]. 
These fields are reserved. 
Please remove them from your documents.

It still works, but it is annoying to see this warning when using this package.
Could we get an option to prevent storing id field within the document?

When creating documents normally, through firestore.collection('name').add(...), the id field is not added to the document.
I think the same should apply for this package.

[wovalle]

Interesting 🤔

Do you know if there's any documentation that says that id should not be used in firestore documents?

[AlexanderArvidsson]

No, I am only basing this on the warning from @nandorojo/swr-firestore.
I have forked the project and added the following lines to serializeEntity:

  ['id', 'exists', 'hasPendingWrites'].forEach(field => {
    delete serializableObj[field];
  });

Works fine for me, but is a little bit of a forced workaround. Maybe we should do the same as swr-firestore and warn the owner if they are using exists or hasPendingWrites.
I could make a pull request, if you wish.

[AlexanderArvidsson]

It does make sense though, look at the fields that every document contains:

Wouldn't this mean that ref, exists, metadata, id are reserved?

[wovalle]

Yeah, maintaining a list of reserved fields can be done.

I'm kind of interested about the id field usage, intertally we depend on it to map collections. I'll try to investigate if it should be used or not.

[glebbash]

+1 We need a way to exclude id field to stay consistent with documents that were not created with fireorm. Currently we are monkey-patching toSerializableObject to exclude id which does not sound like a good idea.

[wovalle]

As of now I don't have time to finish this issue @glebbash :(

From design perspective id is used to map collection but maybe we might not need to store the id field. If that's true, I can check any PRs that remove this limitation