You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is rather clumsy and moves the work to bind the methods to their respective host objects to users although it could easily be done by the library.
Are you interested in a PR that auto binds all methods?
The reason for binding methods on the returned objects is purely to provide a more convenient developer interface. An example use case would be e.g. conversion to promise based / async-await control flows:
This is fixed with a simple function.prototype.bind call, but I'd argue this is inconvenient for library users and adds to general boilerplate code needed.
importGithubfrom'github-api';constgithub=newGithub();asyncfunctionmain(){constrepo=awaitgithub.getRepo('michael','github');returnrepo;}main().then(repoJson=>{// do stuff}).catch(error=>{});
You're going to need to pass things around (whether they're functions or the github instance) so I don't see any advantage to pulling instance methods off of the instance.
I guess to answer the question you asked I don't think that this is something we'd like to support by default. However, if you submit a PR that enables this behind a flag or option upon instantiation then I guess I don't have a problem with it. It just doesn't feel very javascript-y.
See React's reasoning for dropping support for auto-bound methods like this as they transition to ES6+ usage.
Activity
clayreimann commentedon Jun 7, 2016
While the issue you document will currently occur–Javascript in general behaves in this manner–is there a reason to have everything bound by default?
Could you elaborate on your use case for having methods bound? Why not just pass around the objects that the library returns to you?
marionebl commentedon Jun 7, 2016
The reason for binding methods on the returned objects is purely to provide a more convenient developer interface. An example use case would be e.g. conversion to promise based / async-await control flows:
This is fixed with a simple
function.prototype.bindcall, but I'd argue this is inconvenient for library users and adds to general boilerplate code needed.clayreimann commentedon Jun 7, 2016
Why not:
You're going to need to pass things around (whether they're functions or the
githubinstance) so I don't see any advantage to pulling instance methods off of the instance.I guess to answer the question you asked I don't think that this is something we'd like to support by default. However, if you submit a PR that enables this behind a flag or option upon instantiation then I guess I don't have a problem with it. It just doesn't feel very javascript-y.
See React's reasoning for dropping support for auto-bound methods like this as they transition to ES6+ usage.
marionebl commentedon Jun 7, 2016
Thanks for the clarification and fast response. Makes a lot of sense to me. 👍