feat(core): Add client.getIntegrationByName()#10130
Conversation
size-limit report 📦
|
bad4f1e to
da90b3c
Compare
Lms24
left a comment
There was a problem hiding this comment.
Nice! I think this is way cleaner naming-wise and passing a type as a generic makes sense to me!
0421747 to
1ad9c60
Compare
And also deprecate both `getIntegration()` as well as `getIntegrationById()` which is only on the baseclient, but not on the client type, anyhow :grimace:.
Usage:
```ts
const replay = getClient().getIntegrationByName('Replay');
```
Or, if you want to have an easier time with types:
```ts
const replay = getClient().getIntegrationByName<Replay>('Replay');
```
1ad9c60 to
b7b094e
Compare
|
Would appreciate a helper type for the new value integrations this is a bit wild right now: FWIW, I see it still resolves to the class for now, so this is much ado about linter warnings. Would also appreciate it if |
Yeah, I can see that. Maybe we need a helper specifically for replay 🤔 IMHO replay is the only integration where this is really relevant, the idea for integrations overall is that you don't need to access them really ever. I'll see if I can whip up something! |
And also deprecate both
getIntegration()as well asgetIntegrationById()which is only on the baseclient, but not on the client type, anyhow :grimace:.Usage:
Or, if you want to have an easier time with types:
Why do we need this
In v8, integrations will not be classes anymore, so you cannot pass a class definition anymore to
getIntegration(). We also decided to remove the staticidfield, so you cannot find an integration via that way anymore.getIntegrationById()was always just on the baseclient, so not properly types anyhow. It is also an inconsistent/weird naming because we will not have anidanymore for integrations at all.