Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: make Request object thenable #515

Merged
merged 9 commits into from
Jul 26, 2024

Conversation

pablopalacios
Copy link
Contributor

@pablopalacios pablopalacios commented Jul 21, 2024

Now the request object returned by fetchr crud methods are thenable by default.

To make it possible, I had to refactor httpRequest to transform it in a class to make it easier to expose then, catch and abort to the users. By doing it, it was also possible to simplify the Request class and remove some workarounds related to abort.

This PR also implement some of the stuff we discussed in #263 (comment) without the need for a major version bump.

Before

// superagent style
fetchr
  .read('foo')
  .end()
  .then()

// callback style without callback
fetchr
  .read('foo', null) // passing a second params was necessary to not trigger the superagent API.
  .then() 

After

// superagent or callback
fetchr
  .read('foo')
  .then()

This is also quite nice when doing fire and forget calls with async/await:

await fetchr.update('counter');

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

@pablopalacios pablopalacios force-pushed the make-it-thenable branch 2 times, most recently from 8bc6d7c to a5ecd22 Compare July 21, 2024 13:34
In this way we don't need to call .end() to trigger the request when
using promises.
Copy link
Contributor

@redonkulus redonkulus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks ok. I'm assuming there are not breaking changes here and just organization and code improvements?

.params({id: ###})
.end(function (err, data, meta) {
// handle err and/or data returned from data fetcher in this callback
.params({ id: 42 })
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more of a style comment and less about the code changes, but I've never been a fan of this programming style. All of this code was written before async / await was available. I would prefer if the API were something simpler like:

try { 
  // read(/* service */, /* params */, /* config */);
  const data = await fetcher.read('data_service', { id: 42 });
} catch (e) {
  console.log(e);
}

Maybe this is something we change for a 1.x release.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I agree. I only fixed the docs because there are people at my company requiring a more up to date docs. I've also revisited what we discussed on #275 and this is what I want to tackle next. I also think it's possible to make it backward compatible so we can adjust everything before going to v1 and remove all the other APIs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me. BC is ideal but not a blocker if it makes the API better and user friendly.

}, delay);
});
}

function io(options, controller) {
function _fetch() {
var self = this;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: do we still need to use self?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need it later in the fetch call itself. Most of the time we could use this and only self in the fetch promise. But having both would be annoying so I opted to only use one. I was also very tempted to use arrow functions so we wouldn't need this workaround. I was afraid that you would consider it a breaking change, so I kept the es5 style.

}

function delayPromise(fn, delay) {
// _retry is the onReject promise callback that we attach to the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any thing to review in these changes or is it just reorganizing the code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, just reorganizing.

@pablopalacios
Copy link
Contributor Author

Overall this looks ok. I'm assuming there are not breaking changes here and just organization and code improvements?

It's mainly refactoring. Calling .end() without a callback is still possible but I removed all the tests and added a warning for the users.

@pablopalacios
Copy link
Contributor Author

@redonkulus any blocker?

@redonkulus redonkulus merged commit 7d5118f into yahoo:main Jul 26, 2024
2 checks passed
@redonkulus
Copy link
Contributor

Published https://github.com/yahoo/fetchr/releases/tag/v0.7.11

@pablopalacios pablopalacios deleted the make-it-thenable branch July 29, 2024 07:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants