Skip to content
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

[Deprecation]: Remove internal objects from public API #1000

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

seanpdoyle
Copy link
Contributor

@seanpdoyle seanpdoyle commented Sep 12, 2023

Motivation

The removal of exported TypeScript types and a hesitance to introduce statically enforceable JSDoc comments means that the package's is even more responsible for maintaining backwards compatibility and a stable public interface.

While the majority of the application's "public interface" is driven through HTML [data-*] attributes and event listeners, there are some Turbo-defined Class interfaces that applications can interact with.

This pull request aims to reduce the surface area of those public interfaces, with the purposes of:

  • coordinating with consumer applications through built-in classes that the browser provides
  • limiting the backwards compatibility burden
  • freeing up Turbo's internal objects to change over time

Summary

The FetchRequest, FetchResponse, and FormSubmission objects are internal abstractions that facilitate Turbo's management of HTTP and Form Submission life cycles.

Currently, references to instances of those classes are available through event.detail for the following events:

  • turbo:frame-render
  • turbo:before-fetch-request
  • turbo:before-fetch-response
  • turbo:submit-start
  • turbo:submit-end

Similarly, the turbo:before-fetch-request exposes a fetchOptions object that is a separate instance from the one used to submit the request. This means that any modifications to any value made from within an event listener are ineffective and do not change the ensuing request.

Details

This commit deprecates those properties in favor of their built-in foundations, namely:

The properties that expose those instances will remain as deprecations, but will be inaccessible after an 8.0 release.

submitter: this.submitter,

get formSubmission() {
console.warn("`event.detail.formSubmission` is deprecated. Use `event.target`, `event.detail.submitter`, and `event.detail.request` instead")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@afcapel @kevinmcconnell I realize now that the removal of TypeScript in anticipation of an 8.0 release means that a deprecation cycle as part of a minor release is no longer possible.

I'm curious of your thoughts here. Ultimately, we can remove the properties entirely and skip the console.warn calls.

@shiftyp
Copy link
Contributor

shiftyp commented Sep 12, 2023

Congrats, you're the 1000th PR! You win a prize 💯 * 🔟 🥳

@seanpdoyle seanpdoyle force-pushed the fetch-request-read-only branch 2 times, most recently from 6994399 to ed669b8 Compare September 12, 2023 18:23
addEventListener("turbo:submit-start", (({ detail }) => {
detail.formSubmission.method = "get"
detail.formSubmission.action = "/src/tests/fixtures/one.html"
detail.formSubmission.body.set("greeting", "Hello, from an event listener")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The built-in Request class is much more immutable than our internal FetchRequest. All of its properties are read-only, so consumer's wouldn't be able to re-write data like the method, URL, or body. Mostly, consumers can re-write Headers.

Since this wasn't quite possible until #691, it's a breaking change to unreleased behavior.

The `FormSubmission` delegate methods refer to arguments of type
`FetchRequest` as `request`, and arguments of `FetchResponse` as
`response`. Without type annotations to go along with those names, it
isn't clear that `request` is not a built-in `Request` and `response` is
not a built-in `response`.

This commit renames them to communicate their underlying types.
@seanpdoyle seanpdoyle force-pushed the fetch-request-read-only branch from ed669b8 to 1a1bdff Compare March 29, 2024 19:02
@seanpdoyle seanpdoyle marked this pull request as ready for review March 29, 2024 19:03
@seanpdoyle seanpdoyle force-pushed the fetch-request-read-only branch 2 times, most recently from 7ce2a56 to 647323f Compare March 29, 2024 22:45
The `FetchRequest`, `FetchResponse`, and `FormSubmission` objects are
internal abstractions that facilitate Turbo's management of HTTP and
Form Submission life cycles.

Currently, references to instances of those classes are available
through `event.detail` for the following events:

* `turbo:frame-render`
* `turbo:before-fetch-request`
* `turbo:before-fetch-response`
* `turbo:submit-start`
* `turbo:submit-end`

Similarly, the `turbo:before-fetch-request` exposes a `fetchOptions`
object that is a separate instance from the one used to submit the
request. This means that **any** modifications to **any** value made
from within an event listener are ineffective and **do not change** the
ensuing request.

This commit deprecates those properties in favor of their built-in
foundations, namely:

* [Request][]
* [Response][]

The properties that expose those instances will remain as deprecations,
but will be inaccessible after an `8.0` release.

[Request]: https://developer.mozilla.org/en-US/docs/Web/API/Request
[Response]: https://developer.mozilla.org/en-US/docs/Web/API/Response
@seanpdoyle seanpdoyle force-pushed the fetch-request-read-only branch from 647323f to 2a9a0c6 Compare March 29, 2024 22:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants