Skip to content

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

Merged
merged 17 commits into from
Apr 14, 2022
Merged

ref(client): Inject Transports into Client #4921

merged 17 commits into from
Apr 14, 2022

Conversation

Lms24
Copy link
Member

@Lms24 Lms24 commented Apr 12, 2022

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 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.

Specifically, this PR

  • adds the injection logic
  • initializes the transports in Browser and Node and passes them to the Browser/NodeClient initialization
  • adds client-external transport setup functions (extracted from setupTransport())
  • adds basic tests for these transport setup functions
  • deletes the client-internal setupTransport methods
  • fixes a bunch of tests that are initializing clients

ref: https://getsentry.atlassian.net/browse/WEB-792

@github-actions
Copy link
Contributor

github-actions bot commented Apr 12, 2022

size-limit report 📦

Path Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified) 20.17 KB (+0.14% 🔺)
@sentry/browser - ES5 CDN Bundle (minified) 64.27 KB (-0.53% 🔽)
@sentry/browser - ES6 CDN Bundle (gzipped + minified) 18.84 KB (-0.11% 🔽)
@sentry/browser - ES6 CDN Bundle (minified) 57.9 KB (-0.12% 🔽)
@sentry/browser - Webpack (gzipped + minified) 23.36 KB (+0.56% 🔺)
@sentry/browser - Webpack (minified) 81.12 KB (-0.73% 🔽)
@sentry/react - Webpack (gzipped + minified) 23.41 KB (+0.58% 🔺)
@sentry/nextjs Client - Webpack (gzipped + minified) 47.9 KB (-0.32% 🔽)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified) 26.03 KB (-0.16% 🔽)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified) 24.4 KB (-0.32% 🔽)

@Lms24 Lms24 changed the title Inject Transports into Client [WIP] ref(client): Inject Transports into Client Apr 12, 2022
@Lms24 Lms24 force-pushed the lms-inject-transports branch 2 times, most recently from 2275534 to 0c9e746 Compare April 13, 2022 08:42
@Lms24 Lms24 changed the title [WIP] ref(client): Inject Transports into Client ref(client): Inject Transports into Client Apr 13, 2022
@Lms24 Lms24 marked this pull request as ready for review April 13, 2022 15:09
@Lms24 Lms24 force-pushed the lms-inject-transports branch from d759f7a to 86cfd73 Compare April 14, 2022 07:29
Copy link
Member

@lforst lforst left a 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 } {
Copy link
Member

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... 🤔

Copy link
Member Author

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).

Copy link
Member Author

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

@Lms24 Lms24 merged commit 71d1aba into 7.x Apr 14, 2022
@Lms24 Lms24 deleted the lms-inject-transports branch April 14, 2022 11:12
Lms24 added a commit that referenced this pull request Apr 26, 2022
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
lobsterkatie pushed a commit that referenced this pull request Apr 26, 2022
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
lobsterkatie pushed a commit that referenced this pull request Apr 26, 2022
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
AbhiPrasad pushed a commit that referenced this pull request May 30, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants