add map functionality

[meech-ward]

Just a suggestion, not an intentional PR.

.map

const [ error, result ] = await mightFail(axios.get("/posts")).map(post => post.title)

if (error) {
  // handle error
  return;
}

const titles = result.data
titles.map((post) => console.log(title));

---

I just used it inline like this

const [error, project] = await mightFail.all([getProject(params.projectId), getProjectPositions(params.projectId)])
  .map(([projectData, positionsData]) => ({
    ...projectData.project, positions: positionsData.positions
  }))

its way nicer than shit like this:

  const projectData = await mightFail(Promise.all([getProject(params.projectId), getProjectPositions(params.projectId)])
    .then(([projectData, positionsData]) => ({
      ...projectData.project, positions: positionsData.positions
    }))
  )

@iliaamiri what do you think?

[iliaamiri]

Agreed. The implementation of it is neat too. I see that the Go style isn't implemented. Want me to help with adding that part?

Also, this would kind of open the door for having other transformative functions like .reduce, .filter, .some if needed. Personally haven't had a use-case for it although I can see the convenience and the clean syntax of it to be appealing.

[meech-ward]

I don't know, i'm not sure if it's a good idea yet. I had claud and open code do most of the work

[iliaamiri]

Will think about it more as well. Ok

[meech-ward]

@iliaamiri I think it's a good idea. what do you think?

[iliaamiri]

@meech-ward Initially, I was against the idea because it feels like we're adding too many utilities to the library. But, after joggling between so many thoughts, I reached to a point where I don't see why not.

The mindset of adding utilities around the Either type is what convinces me not to be against it because we literally have Promise utilities or Might and Fail constructors which are Either utilities in their own way.

[iliaamiri]

Regarding the naming, I initially thought this is same functionality as .map in JavaScript.

I've seen similar idea in functional programming where they call it the pipe operator. Very similar to this idea.

I'm purposing to rename it to .pipe instead of .map to give the same idea to the users immediately and not to be confused with the regular .map higher-order function. What do you think?

[iliaamiri]

Here I believe maybe the linter automatically rmoved .js from the imports which we added based on issue #25 ?

[meech-ward]

I think this is more map than pipe. Especially since we're not "piping" the output directly to the next thing. We're transform what’s inside the wrapper, the promise, before it's been awaited.

[iliaamiri]

@meech-ward That's an interesting way to look at it. And I mean as long as the user reads the docs carefully, there shouldn't be any problems then.