Closed deongroenewald closed 2 months ago
Thanks for the report and PR.
For this specific case of add
, it happens that the current implementation will not pass null
for the error, so I'll go ahead and get this in to resolve the unintentional breaking change.
However, in the general case on Node-style callbacks with results, null
can commonly be passed for the error.
On Node-style callbacks:
For a function implementation, the standard way of calling the callback with a result does include null
:
// with result and no error
callback(null, result);
// with no error
callback();
Node's core library type definitions have numerous examples of this - they actually don't include undefined
:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/d8e5f63a03750e5711e42cdc7bff942fc9e31e93/types/node/fs.d.ts#L2733-L2741
ShareDB's query code can invoke the callback with either approach in the example above: https://github.com/share/sharedb/blob/f4effa3a73c840cfeff8ed59371fda16516d7ad9/lib/client/query.js#L155
Now, for op submissions, ShareDB doesn't provide a result, so the error will only be undefined
or an Error. The new Racer code for the model.add
callback getting the id
result just passes through the error or lack thereof, so it happens that the error will never be null
.
The introduction of the
ValueCallback
type in #305 inadvertently introduced a breaking change in the types.It adds an additional constraint that the passed-in callback function must also expect
null
as a possible value for theerr
parameter in addition toError
andundefined
whereas theErrorCallback
type does not.I don't believe
null
is a possible return value for theerr
parameter based on the previous code so suggest removing thenull
from the union type forerr
inValueCallback
so that it matchesErrorCallback