lune-climate / ts-results-es Goto Github PK

Hey currently using the library quite extensively in an express app and it makes the data flow really easy to reason about.
Right now though I think it can either improve my code, or contribute to the library for some piece of code that seems to be recurring and need some inspiration from you folks

Here is the use-case

  const arrayData: AsyncResult<Array> = getDataAsyncResult();

  arrayData.andThen(async (array) =>
    Result.all(
      await Promise.all(
        array.map((p) => {
          return p.andThen((refinedData) => processDataAsyncResult(refinedData)).promise;
        }),
      ),
    ),
  );

Most of
Right now I need to translate from AsyncResult to Result most of the time in order to aggregate all of the AsyncResult into a single result (Which I can then do an toAsyncResult() if necessary)

The idea would be to have a method on AsyncResult.aggregate which would be able to process the array received and return an AsyncResult or a Result (The same way Result.all does).

What do you think? Or am I using the library in a weird way?

I'm a bit confused on how to import rxjs operators from this fork.

This seems to not work:

import { filterMap } from 'ts-results-es/rxjs-operators' //Cannot find module 'ts-results-es/rxjs-operators' or its corresponding type declarations

However,

import { filterMap } from 'ts-results-es/esm/rxjs-operators'

Should work.

BUT I assume that would remove compatibility for common js.

Any solution to fix this issue?

I wanted to use it today and I found out it was missing.

https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap_err

Version: 3.3.0 (latest)
react-scripts: 5.0.1

When I start the project, I get the following warnings

The project compiles with warnings: Failed to parse source map from '/.../node_modules/src/index.ts' file: Error: ENOENT: no such file or directory, open '/.../node_modules/src/index.ts'

on stackoverflow they just write to disable warnings, add to .env

GENERATE_SOURCEMAP = false

but it seems to me that this is wrong

In an async heavy test (fuzzy testing with a lot of requests and network issues simulated with toxiproxy), rewriting a bit of the code with ts-results-es made the test fail.

I tracked the issue down to the stack trace generation in Err(), which was taking ~300ms parsing the source maps. I removed it entirely in this fork, which solved the issue.

I'm not sure how or if this should be fixed here, just wanted to report the issue.

Is there any way to use mapErr (or another method) in a manner that lets me transform the error into valid result. Such that when unwrapping at the end, nothing is thrown?

I am essentially trying to achieve the following:

function doThing() {
  const result = getResult();

  return result
    .map(() => getSuccessResponse())
    .mapErr(err =>     mapErrIntoSuccessResponse())
}

in this case, i wouldn’t want mapErr branch to throw at the end (unless mapErrInoSuccessResponse itself throws)

Relevant issue in the upstream repository: vultix#33

Basically it's really inconvenient to mix Option and Result with promises right now because a Promise<Option<...>> or Promise<Result<...>> needs to be awaited first in order to use any of the composition/combination methods (like map(), andThen() etc.)

Some code I wrote today:

// readFileChecked() returns Promise<Result<Buffer, ...>>
// parseCsvChecked() takes Buffer and returns Result<object[], ...>

const rawContent = await readFileChecked(path)
if (rawContent.isErr()) {
    return rawContent
}
return rawContent.andThen(parseCsvChecked)

What I wish I could write is:

return readFileChecked(path).andThen(parseCsvChecked)

Any ideas about the API or the design of this feature are welcome.

Howdy! Thanks for being so welcoming to new PRs and ideas. I'm excited to use the new features we've added natively. When can we expect a new release?

Thank you for the updated library, are you interested in adding the Variant Implementation to enable matching, like proposed in this PR vultix#61 ? That would be a tremendous improvement

Basically, I want to figure out what the solution is to not having the question-mark operator from Rust.

That is, given this:

const triggerForEventsResult = await task.triggerForEvents();
if (triggerForEventsResult.isErr()) {
  return triggerForEventsResult;
}
const triggerForEvents = triggerForEventsResult.value;

Is there a more concise/idiomatic way to write this? I'm getting flashbacks to my Golang time with if err != nil all over the place.