About Swift Firestore Result

Where did the result come from?

Result is the type contained in the Swift standard library.
Result

As in the past, two variables are used to "return non-nil values to result for success, and nil for error.In the case of failure, put nil in result and error in non-nil values" commitment assumes that both result and error cannot be nil on Swift's type system.

Result is followed by the following initializer:

init(catching:)

This initializer generates Result.failure(...) when Error is thrown in the closure and Result.success(...) when a return value is returned without ending the error.

I don't understand why this Result is optional in let.

let appears in several places in your code, so if you clarify which part you are referring to, it will be easier to get a more accurate answer.

We assume that this is the case.success(let city) part.

What we are testing here is whether try document?.data(as:City.self) threw a Error. document is optional, so data(as:) results from data(as:) without calling the method.

Apart from the successful document, I don't know why I'm using Result.

It's a good example not to think that the original code is very hard to see (it's a code published by Google all over the world, so it's written in a good way).It's partly because of this, but it doesn't seem to be fully understood where the success/failure is determined.

• getDocument Success/Fail

  Success: document is non-nil, error is nil
  Failed: document is nil, error is non-nil

• data(as:)Success/Failure

  Success:result has a value of .success(City?)
  Failed: result has a value of .failure(Error)

  この Success in this case includes cases where document is not called data(as:) because of nil

getDocument Success/Fail

Success: document is non-nil, error is nil
Failed: document is nil, error is non-nil

data(as:)Success/Failure

Success:result has a value of .success(City?)
Failed: result has a value of .failure(Error)

この Success in this case includes cases where document is not called data(as:) because of nil

In other words, if getDocument itself fails and document contains nil.

At the very least, if you want to use the code to express clearly that you are checking where and what kind of errors are occurring, the code you listed is not a passing point.

For example, would writing like this make it a little easier to understand?

let docRef=db.collection("cities").document("BJ")

        docRef.getDocument {( document, error) in
            iflet error = error {
                print(error)
                return
            }
            guardlet document= document else {
                print("Document does not exist")
                return
            }
            do{
                let city=try document.data(as:City.self)
                print("City:\(city)")
            } catch{
                print("Error decoding city:\(error)")
            }
        }