Thoughts on findArray networking issues

[cheneveld]

If a server response for a findArray call is not a success, only an empty array is returned, and no way to distinguish that something went wrong.

Thoughts on this?

Should the response object be passed to the calllback?
or maybe an error object?

[erkie]

I would say add an error parameter at the end of all callbacks really. I have a bad habit of ignoring errors, which shouldn't be the default...

I guess with that improvement we should also perhaps look into standardizing what the Api-callbacks return. Right now it's a mix of Api<T>, ModelType?, [ModelType] and (ApiModelResponse<ModelType>). I don't think one unified response callback would be advisable, since it would impede usability (since not all data is needed in every use-case)

What do you think?

[erkie]

Thinking about it again, another option that would not require adding error parameters, is to make the findArray callback: [ModelType]? i.e nil if a response failed.

In addition the the question above: For example in your case, would you use the a detailed error object for anything? For example do you need it to take a specific action, or different messaging to the user?

[cheneveld]

The nil option isn't meaningful enough. Is the backend down? Did the path change? What happened?

I like the idea of standardizing all the calls and passing meaningful error/response objects back to the caller.

Pondering still

[cheneveld]

#31 addresses this question.

Find methods now take apiModelResponse as a parameter, and objects will be nil if "server" errors occur