Make emptyObject more developer friendly

[vdkdamian]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Currently the developer needs to add a emptyObject to the ParseObject struct

Feature / Enhancement Description

Adding a Updatable protocol

Example Use Case

struct GameScore: ParseObject, Updatable {
    //: Those are required for Object
    var objectId: String?
    var createdAt: Date?
    var updatedAt: Date?
    var ACL: ParseACL?

    //: Your own properties.
    var score: Int = 0
}

var changedScore = savedScore.updatable
changedScore.score = 200
changedScore.save { result in
    switch result {
    case .success(var savedChangedScore):
        print("Succes")

    case .failure(let error):
        assertionFailure("Error saving: \(error)")
    }
}

Alternatives / Workarounds

struct GameScore: ParseObject {
    //: Those are required for Object
    var objectId: String?
    var createdAt: Date?
    var updatedAt: Date?
    var ACL: ParseACL?

    //: Your own properties.
    var score: Int = 0

    /*:
     It's recommended the developer adds the emptyObject computed property or similar.
     Gets an empty version of the respective object. This can be used when you only need to update a
     a subset of the fields of an object as oppose to updating every field of an object. Using an
     empty object and updating a subset of the fields reduces the amount of data sent between
     client and server when using `save` and `saveAll` to update objects.
    */
    var emptyObject: Self {
        var object = Self()
        object.objectId = objectId
        object.createdAt = createdAt
        return object
    }
}

3rd Party References

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[cbaker6]

Moving the emptyObject property to a protocol the developer can chose to add on their own will make it easier for them. Though if #263 gets to a working state, emptyObject won’t be needed anymore. We would need to think of a different name than Updatable though, maybe ParseObjectMutable and then name the property mutable. The naming change would imply that conforming to the protocol makes the ParseObject mutable for Parse purposes as opposed to general purposes.

[vdkdamian]

@cbaker6 So should I continue adding your recommended changes? Or you think it's not needed to add this because of the solution #263 would offer?

[cbaker6]

Yes, I think it’s still worthwhile. The protocol will make things easier and the 263 still needs work before it can be merged