Closed rzadp closed 1 year ago
I'd consider deprecating those, actually.
This is a practice coming from the Rust world (and in Rust, I love it), but it goes against common JS/TS practices, where throws and try-catches are standard.
WDYT?
I'd consider deprecating those, actually.
I agree here, if they don't provide that much use and are a danger, let's deprecate them and later remove them
Ok, I have created this instead then: https://github.com/paritytech/opstooling-js/pull/36
The (potential) problem
I worry that relying on
instanceof Ok/Err
in packages consumingopstooling-js
can be dangerous.Example usage
It is safe if the class is declared in your code, but if the class is declared in a dependency I think it's not always safe.
Multiple
opstooling-js
in node_modulesThat's it, there now exist two different
opstooling-js
packages in node_modules. Can we be sure that when doingsomething instanceof Err
both left-side value and right-side type are coming from the same package? I'm not so sure, I've run into problems like this before, but maybe I'm missing something.The proposed solution
Replace the
Ok/Err
classes with interfaces. Now you cannot doresult instanceof Ok
, you have to doresult.kind === "Ok"
, which I think resolves this potential problem.