🍪 Multi-Cookie Use Alternative Solution

[EvanZhouDev]

Alternative Solution to Multi-Cookie Use (#12)

This solution causes a minor breaking change, documented at the end.

Bard.init() now returns an object. This object contains its own askAI and Chat functions, all linked to the SNlM0e generated from the initialization. In fact, Bard.init() can still set the global SNlM0e, allowing global askAI() and Chat to still work normally.

For example, it could look something like this:

let myBard1 = Bard.init(COOKIE_KEY_1)
let myBard2 = Bard.init(COOKIE_KEY_2)

myBard1.askAI("hi!") // uses COOKIE_KEY_1
let myBardChat1 = new myBard1.Chat() // uses COOKIE_KEY_1

myBard2.askAI("hi!") // uses COOKIE_KEY_2
let myBardChat2 = new myBard2.Chat() // uses COOKIE_KEY_2

The one concern is that Bard.init() used to return SNlM0e as a string, but now rather returns what is similar to an entire Bard instance...

[EvanZhouDev]

Wait... it's possible to not have a breaking change. The method is to make a new function that does all of this, that's not init. init would have the same thing, and will slowly be filtered out, deprecated, and eventually removed.

[ThatXliner]

As long

Wait... it's possible to not have a breaking change. The method is to make a new function that does all of this, that's not init. init would have the same thing, and will slowly be filtered out, deprecated, and eventually removed.

init returning a string is undocumented in the first place (except through the TypeScript type), so this shouldn’t be a breaking change.

[EvanZhouDev]

Or to be honest, we can just have new Bard(COOKIE_KEY), and the rest of the methods be Static methods under that. What do you guys think?

[ThatXliner]

Or to be honest, we can just have new Bard(COOKIE_KEY), and the rest of the methods be Static methods under that. What do you guys think?

Wouldn't that break importing and tree-shaking (don’t know; haven’t tried it yet)?

[Aldhanekaa]

Or to be honest, we can just have new Bard(COOKIE_KEY), and the rest of the methods be Static methods under that. What do you guys think?

I like this idea, the way we create new Instance of Bard, because by knowing it's a class and we can create an Instance. It's readable that we can make endless connection to Google Bard API (because we know it is a class), rather than just Bard.init.

You also mentioned that, if we had new Bard(COOKIE_KEY), the rest are static methods, and I think what you mean by static methods are for the askAI function, this can adding more complexity because, if the askAI is a static function, then we would have to pass the instance of Bard class—along with message, and useJSON.

So I would go with your first solution, which back to use Bard.init https://github.com/EvanZhouDev/bard-ai/issues/15#issue-1773965583

[ThatXliner]

Or we could v2 and avoid global state all together and re-imagine the API supporting multiple cookies from the ground up

[EvanZhouDev]

@Aldhanekaa What I mean is that the static methods would use global.

But I agree with @ThatXliner that maybe we should consider a v2. Should we do it?

[EvanZhouDev]

Multi-cookie use will be available in Version 2. See #30.

Closing... feel free to re-open if necessary.