4 ms·
Do you mean: Failure { error: Error } Success<T> { value: T } I assume you want value or error not value and error.
by eeperson 7y ago
Do you mean:
Failure { error: Error }
Success<T> { value: T }
I assume you want value or error not value and error.
- holtalanm 7y agoeh. the pattern he is trying to mimic from elixir is: {:ok, value} or {:error, err} so, you would be correct.
- valand 7y agoLimitation in TypeScript. Even in TS 3.6.x you can't do ``` if (result.error) { ... } ``` on a variable that possibly returns { value: T } It'll complain that result may possibly have no attribute error
- sondang 7y agoYou can do: if ('error' in result) { console.error(result.error); // ok: result inferred as 'Failure' } else { doThings(result.value) // ok: result inferred as 'Success<T>' } Even though you used string there, it's pretty type-safe because if you have a typo in your string, the inferred types will propagate other type errors if ('errors' in result) { // typo console.error(result.errors); // Type error: result inferred as 'never' } else { doThings(result.value) // Type error: result inferred as Success<T> | Failure }
- paulddraper 7y agoThe discriminated union pattern is better [1] type Success<T> = { type: 'success', value: T}; type Error = { type: 'error', value: string }; type Result<T> = Success<T> | Error; if (result.type === 'error') { result.error; } else { result.value; } [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions https://www.typescriptlang.org/docs/handbook/advanced-types....
- felipellrocha 7y ago... What do you expect here? The compiler is doing exactly what is expected.