Open nlunets opened 1 year ago
Hm. The situation is like this:
So what exactly is your request? that the base class "Model" should document the return type as "null" instead of "undefined"? (the one in error case of course) That would seem to make sense.
Or that in addition the the original ODataModel admits it might also return "undefined" and the v2.ODataModel admits it might also return "null"??
@uhlmannm and @pksinsik can you please take a look at this? V4 never returning null
or undefined
is okay for TypeScript, but the others should align on a signature that they inherit from the base class.
I would assume that for the widely used models, compatibility "rulz". Extending the base signature to both, undefined
and null
might be the only way to fix this. But maybe you're more optimistic reg. a leaner solution (e.g. as v2 ODataModel
does not document the null
, can it replace it with undefined
?).
So what exactly is your request? that the base class "Model" should document the return type as "null" instead of "undefined"? (the one in error case of course) That would seem to make sense.
I wish for every model to confirm what they return properly at least :) so yes returning null instead of undefined feels better.
Regarding v4, it actually throws error when something is not ok which might be contrary to the philosophy of the models in general.
@codeworrior We should not change the cases where v2.ODataModel#createBindingContext returns null to return undefined; same is true for ClientModel. Reason is - compatibility... If you say TypeScript really requires it we may enhance the return value documented for Model#createBindingContext.
If you say TypeScript really requires it we may enhance the return value documented for Model#createBindingContex
Isn't correctness also a good reason to change documentation?
we will work on the topic "fix jsdoc for null value for a context resp. optional oContext parameters across APIs for base model, client models, v2.ODataModel classes" via the existing incident 2270138264 already opened by @nlunets
sap.ui.model.Model.prototype.createBindingContext says it returns a Context | undefined.
however the ClientModel already returns Context | null it seems :/
That's pretty annoying if you want to have proper null checks :)