types: fix the type of the QuansyncFn.bind

[wangziling]

Enable to bind this for quansync function.

[sxzz]

Could you please provide a practical demonstration of this use case?

[wangziling]

Hi~

Hmmm...

Here's the story.

Firstly I'm reading the source code of this repo.
When I read the test codes, I've recognized that here exists a test that says it is tested for the bining this scenario but its code only use .call(this) invoking. So I tried to use quansync(fn).bind(this).

See: I had added a new param for the fn named _num to do further tests.

The type annotation indicates that the newFn is a QuansyncFn,
BUT, it is not, it should lose its async and sync methods.
It will not contains the async and sync methods after invoking fn.bind().

So I firstly fixed the bind type, let it notices users that the bound fn didn't own the sync and async methods.

And then I recognized that maybe we should provide a convenient way to bind this for the quansync(fn) and it should remain the sync and async methods with the bound this functionality as well, so I make a bindThis functionality, rather than overwriting a .bind method on it to not to shadow the original bind method on the prototype.

AND I am wondering should we overwrite the .bind method on the Quansync(fn) to do the bindThis functionality?

Here are the cases:

What if users invoke the bind(this) in the React?

this.xxx = this.xxx.bind(this);

Or what if users use it in the Vue?

new Vue({
  methods: {
    someFunc: quansync(fn),
    invokeSomeFunc () {
      // `undefined` is not a function.
      // The type check will come up an error to notice users the `.sync` is not exists.
      this.someFunc.sync();
    }
  }
});

[sxzz]

I’m uncertain whether this helper function is truly necessary. Instead, we could simply clarify in the documentation that bind should only be applied to the calling function, allowing users to implement it themselves if needed.

fn.call(this) // call directly  
fn.sync.bind(this)  
fn.async.bind(this)  

Additionally, preserving bind in the return type can be beneficial.

[wangziling]

I’m uncertain whether this helper function is truly necessary. Instead, we could simply clarify in the documentation that bind should only be applied to the calling function, allowing users to implement it themselves if needed.

fn.call(this) // call directly  
fn.sync.bind(this)  
fn.async.bind(this)  

Additionally, preserving bind in the return type can be beneficial.

Okay I got it~ 😉

[wangziling]

I’m uncertain whether this helper function is truly necessary. Instead, we could simply clarify in the documentation that bind should only be applied to the calling function, allowing users to implement it themselves if needed.

fn.call(this) // call directly  
fn.sync.bind(this)  
fn.async.bind(this)  

Additionally, preserving bind in the return type can be beneficial.

🤣 Wait a minute~

Did I misunderstand what you said.

You mean we need to provide a new returned method named bind to help user to conveniently bind this and preset params for returned fn itself, fn.async and fn.sync.

If yes, let me yied a new commit for it. 🤣

[sxzz]

No, as-is is fine.