Should not ask user to jsonEncode when using the SDK

[bidoubiwa]

Problem

When using the SDK, before each call an object must be encoded in JSON. But the returned object are already decoded into the expected type. This lacks in coherence

Exemple

In the following example I had to JSONEncode my movie into the Data type before adding it to the document parameter of addDocuments.
When In the second request I use the method getOneDocument, I recieve my movie back not as a Movie type and not as a Data type.

It should either be Data to Data, or Swift type to Swift type.

    func testAddAndGetOneDocuments() {
        let movie: Movie = Movie(id: 10, title: "test", comment: "test movie")
        let documents: Data = try! JSONEncoder().encode([movie])

        let expectation = XCTestExpectation(description: "Add or replace Movies document")

        self.client.addDocuments(
            UID: uid,
            documents: documents,
            primaryKey: nil
        ) { result in
            switch result {
            case .success(let update):
                XCTAssertEqual(Update(updateId: 0), update)
                expectation.fulfill()
            case .failure(let error):
                XCTFail(error.localizedDescription)
            }
        }
        self.wait(for: [expectation], timeout: 1.0)
        sleep(1)
        let getExpectation = XCTestExpectation(description: "Add or replace Movies document")
        self.client.getDocument(
            UID: uid,
            identifier: "10"
        ) { (result: Result<Movie, Swift.Error>) in

            switch result {
            case .success(let returnedMovie):
                print("HELLO")
                print(returnedMovie)
                XCTAssertEqual(movie, returnedMovie)
                getExpectation.fulfill()
            case .failure(let error):
                XCTFail(error.localizedDescription)
            }
        }
        self.wait(for: [getExpectation], timeout: 3.0)
    }

Solution

I prefer that the user sends its data using its specific type (in this case Movie). Swift will most likely be used for front end matter so while I understand that it makes it more complex to add a "big json" to meilisearch, i'm not sure any user will use swift to add documents to meilisearch (maybe i'm wrong). And in the rare cases it does, the data will come from whatever form the user completed and thus the data will be in a given format (i.e: Movie) and not in a jsonString.

In this case, the function prototype will look like this:

public func addDocuments<T>(
        UID: String,
        documents: T,
        primaryKey: String?,
        _ completion: @escaping (Result<Update, Swift.Error>) -> Void) {
        self.documents.addOrReplace(
            UID,
            documents,
            primaryKey,
            completion)
    }

[ppamorim]

@bidoubiwa The problem is to create a type internally that accepts Data and Encodable, I am fighting with the compiler to find a solution.

https://stackoverflow.com/questions/62252547/value-of-protocol-type-encodable-cannot-conform-to-encodable-only-struct-en

[ppamorim]

Another problem is the JSONEncoder, there is a problem to deal with custom date formats. I am not sure how to do this, it looks very intrusive.

[ppamorim]

It was decided to keep both functions in place for the given reasons:

• Replacing the function addDocuments(UID:documents:...) with addDocuments<T>(UID:documents:...) can be breaking change.
• The function addDocuments<T>(UID:documents:...) forces the developer to write Codable objects for each data set in the application, Codable objects cannot be easily created in runtime and the function addDocuments(UID:documents:...) seems to be a better alternative for data created/provided in runtime.
• It will force developers with objc application to write Codable objects in Swift instead of simply using NSJSONSerialization already provided in objc that returns a NSData (transparent to Data). Knowing this, this new function addDocuments<T>(UID:documents:...) will be focused on Swift projects and will be recommended only for explicit types in applications.
• Forcing the developer to decode Data -> [Codable] will be an overhead, especially knowing that the SDK will encode back to [Codable] -> Data when requesting the server.