-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
ref(client): Inject Transports into Client #4921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
size-limit report 📦
|
2275534
to
0c9e746
Compare
all tests will need refactoring once the new transports become the default
d759f7a
to
86cfd73
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work!
* this function will return a ready to use `NewTransport`. | ||
*/ | ||
// TODO(v7): Adjust return value when NewTransport is the default | ||
export function setupNodeTransport(options: NodeOptions): { transport: Transport; newTransport?: NewTransport } { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requires no action now but we should think about moving the contents of this function back into the init function when we get rid of the old transports. Reason being that this function will be reduced to about 5 lines, making it just a weird proxy for makeNodeTransport
.
Same goes for setupBrowserTransport
. Although I do realize we have just written tests for those functions... 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes these setupXTransport
functions will get much smaller, once the old transports are removed, agreed. Let's see how/where we handle ClientOptions. This will probably be the place to set up transports then (or pass on a custom one).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And regarding setup tests: They don't have to stay. I just quickly added them to test setup functionality explicitly. Kinda makes sense at least for fetch vs xhr on the browser side IMO. But let's see if/where they stay when we declutter/restructure the transport setup
packages/node-integration-tests/suites/sessions/errored-session-aggregate/test.ts
Outdated
Show resolved
Hide resolved
Changes the way we initialize Transports. Previously, the Transport was initialized within the Client constructor (by calling setupTransport()). Change this so that the Transport is initialized beforehand and then injected into the client. This is currently (i.e. with this PR) happening via two additional arguments in the Client class constructors. The reason for two arguments is that we're still using both, the old `Transport` classes and the `NewTransport` interface. In the future, `NewTransport` will replace `Transport` and (once the old Transport is removed) the transport is then passed into the Client constructor as a property of the options object. * add the injection logic * initialize the transports in Browser and Node and pass them to the `Browser/NodeClient` initialization * add client-external transport setup functions (extracted from setupTransport()) * add basic tests for these transport setup functions * delete the client-internal setupTransport methods * fixe a bunch of tests that are initializing clients
Changes the way we initialize Transports. Previously, the Transport was initialized within the Client constructor (by calling setupTransport()). Change this so that the Transport is initialized beforehand and then injected into the client. This is currently (i.e. with this PR) happening via two additional arguments in the Client class constructors. The reason for two arguments is that we're still using both, the old `Transport` classes and the `NewTransport` interface. In the future, `NewTransport` will replace `Transport` and (once the old Transport is removed) the transport is then passed into the Client constructor as a property of the options object. * add the injection logic * initialize the transports in Browser and Node and pass them to the `Browser/NodeClient` initialization * add client-external transport setup functions (extracted from setupTransport()) * add basic tests for these transport setup functions * delete the client-internal setupTransport methods * fixe a bunch of tests that are initializing clients
Changes the way we initialize Transports. Previously, the Transport was initialized within the Client constructor (by calling setupTransport()). Change this so that the Transport is initialized beforehand and then injected into the client. This is currently (i.e. with this PR) happening via two additional arguments in the Client class constructors. The reason for two arguments is that we're still using both, the old `Transport` classes and the `NewTransport` interface. In the future, `NewTransport` will replace `Transport` and (once the old Transport is removed) the transport is then passed into the Client constructor as a property of the options object. * add the injection logic * initialize the transports in Browser and Node and pass them to the `Browser/NodeClient` initialization * add client-external transport setup functions (extracted from setupTransport()) * add basic tests for these transport setup functions * delete the client-internal setupTransport methods * fixe a bunch of tests that are initializing clients
Changes the way we initialize Transports. Previously, the Transport was initialized within the Client constructor (by calling setupTransport()). Change this so that the Transport is initialized beforehand and then injected into the client. This is currently (i.e. with this PR) happening via two additional arguments in the Client class constructors. The reason for two arguments is that we're still using both, the old `Transport` classes and the `NewTransport` interface. In the future, `NewTransport` will replace `Transport` and (once the old Transport is removed) the transport is then passed into the Client constructor as a property of the options object. * add the injection logic * initialize the transports in Browser and Node and pass them to the `Browser/NodeClient` initialization * add client-external transport setup functions (extracted from setupTransport()) * add basic tests for these transport setup functions * delete the client-internal setupTransport methods * fixe a bunch of tests that are initializing clients
This PR changes the way we initialize Transports. Previously, the Transport was initialized within the Client constructor (by calling
setupTransport()
). With this PR, we change this so that the Transport is initialized beforehand and then injected into the client. This is currently (i.e. with this PR) happening via two additional arguments in theClient
class constructors. The reason for two arguments is that we're still using both, the oldTransport
classes and theNewTransport
interface. In the future,NewTransport
will replaceTransport
and (once the old Transport is removed) the transport is then passed into the Client constructor as a property of theoptions
object.Specifically, this PR
Browser/NodeClient
initializationsetupTransport()
)setupTransport
methodsref: https://getsentry.atlassian.net/browse/WEB-792