ApiModel icon indicating copy to clipboard operation
ApiModel copied to clipboard

Thoughts on findArray networking issues

Open cheneveld opened this issue 9 years ago • 4 comments

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?

cheneveld avatar Jan 14 '16 22:01 cheneveld

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 avatar Jan 16 '16 14:01 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?

erkie avatar Jan 16 '16 14:01 erkie

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 avatar Jan 19 '16 15:01 cheneveld

https://github.com/erkie/ApiModel/pull/31 addresses this question.

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

cheneveld avatar Jan 21 '16 19:01 cheneveld