FR: RTDB/Codable: Add support for mapping node IDs to / from attributes on a Swift struct

[peterfriese]

Feature proposal

• Firebase Component: Database

Mapping data between RTDB nodes and Swift structs has become a lot easier thanks to the addition of Codable support. However, the current implementation doesn't allow for automatically mapping a node's ID to an attribute on the respective Swift struct. To deal with this situation, developers add an extra field id to their RTDB nodes, which might eventually result in a mismatch between this extra attribute and the actual node ID.

I propose to add a property wrapper similar to the one we use in Firestore (@DocumentID) to

• map node IDs to the thusly annotated attribute on the Swift struct
• use childByAutoId to generate node IDs for new nodes if the attribute annotated with the property wrapper has a nil value

A possible name for the property wrapper might be @NodeID, to match the @DocumentID we use for Firestore.

Context

• https://github.com/firebase/firebase-ios-sdk/tree/master/FirebaseDatabaseSwift/Sources/Codable
• https://brontoxx.medium.com/60d6299369f1

[mortenbekditlevsen]

Regarding the second bullet: In Firestore, the DocumentID property wrapper is not taken into account upon encoding, only decoding, so this would be a different behavior from the current Firestore feature.

[mortenbekditlevsen]

A big difference between Firestore and RTDB is the concept of documents and collections in Firestore. In my eyes, this difference makes it much more comment to subscribe to changes on collections of entities or to have nested entities in RTDB. This means that one snapshot more often will not mean one entity, and thus the concept of @NodeID becomes a bit more muddied.

Other than that I would argue that @DocumentID can be a bit problematic in a few regards:

• Adding a DocumentID property makes your model dependent on the entire Firestore module. Many would argue that the model layer is better kept as thin as possible.
• It also ties the entity very hard to the Firestore.Decoder since trying to decode it with anything else will cause a crash. Meaning that the same entity can't be reused - for instance across Firestore and Functions - or Firestore and RTDB - or Firestore and JSON serialization. This goes against the principle of Codable that codability of an entity is kept separate from the actual encoder/decoder.
• It's easy to misunderstand the purpose. As an example you may think that you can define the id/key of the entity for saving.
• It's easy to model yourself if you really wish. The only decoding that the current API makes available, is on DocumentSnapshot, where you have the documentID present. So if you really want to half-way make it part of your model, you can set it after parsing on a property with a type that does no encoding.
• The current implementation makes it hard to evolve from using a DocumentID property to using an actual model property and also from using an actual model property to a DocumentID property - since the presence of the key in the parsed structure will cause a crash when parsing a `@DocumentID'.
• The id/key of an object belongs to a slightly different domain than the other properties - it belongs more in the domain of where the object is stored - like the complete path. This becomes evident in the fact that the property must be optional and that the encoding and decoding is not symmetrical.

IMHO it would be better not to include something similar for RTDB.

[paulb777]

Assigning to @peterfriese for a response to ^