Closed Aldhanekaa closed 1 year ago
Actually, I would like to bring this further: bring all the private variables public. That way if someone really needs to tinker with the internals, then they don't have to wait on a new release (or their own custom fork). Remember, if it's never mentioned in the documentation, it's an implementation detail that should not be relied on
This principle is especially prevalent in the Python community where private variables/properties do not exist.
Interesting. @Aldhanekaa I agree with @ThatXliner... what do you think?
Interesting. @Aldhanekaa I agree with @ThatXliner... what do you think?
Agree with this! I also consent with header variable being private, because, maybe there will be more header key to access Google Bard API.
I agree with the idea, but do you guys think fetch
private variable shall be public?
I think both verbose
and fetch
could have their official APIs to be patching the JS object. The best API is no API
Sorry I don't quiet get what you mean, does that mean both verbose
and fetch
shall be public?
https://github.com/Aldhanekaa/bard-ai/blob/10ee8563b1f0f223b0569a4ba887be9d8e512dab/index.js#L24-L25
Imagine if these settings weren't part of the config but in fact the way to change it is to patch the JS object (modify the properties after instantiation). On second thought, it wouldn't work since we call fetch on construction
:shipit: Looks good to me!
It's unclear how to clearly knows whether if it has succeeded fetched the Google Bard SNlM0e, so by making
initPromise
visible aims for user to clearly know whether the library has fetched the Google Bard SNlM0e.