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

FormData refactor #34

Merged
merged 3 commits into from
Mar 2, 2018
Merged

FormData refactor #34

merged 3 commits into from
Mar 2, 2018

Conversation

mbyczkowski
Copy link
Contributor

@mbyczkowski mbyczkowski commented Mar 1, 2018

This brings FormData back.

You can just do (it's available globally in the runtime):

const fd = new FormData

or get it straight from the Response:

const fd = response.formData()

Implements #16

@coveralls
Copy link

coveralls commented Mar 1, 2018

Pull Request Test Coverage Report for Build 329

  • 0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
  • 95 unchanged lines in 9 files lost coverage.
  • Overall coverage decreased (-0.8%) to 65.486%

Files with Coverage Reduction New Missed Lines %
src/bridge/fetch.ts 2 91.89%
src/server.ts 2 67.35%
src/context.ts 2 83.65%
src/utils/buffer.ts 3 75.0%
src/bridge/heap.ts 5 37.5%
src/v8env.ts 12 71.43%
src/bridge/fly/cache.ts 16 69.44%
src/bridge/formdata.ts 22 8.82%
src/utils/build.ts 31 20.0%
Totals Coverage Status
Change from base Build 322: -0.8%
Covered Lines: 721
Relevant Lines: 1043

💛 - Coveralls

@mbyczkowski mbyczkowski changed the title [WIP] FormData refactor FormData refactor Mar 1, 2018
@jeromegn
Copy link
Member

jeromegn commented Mar 1, 2018

This is probably a good first step, but I don't think it's following the spec (not that the previous implementation was especially spec-compliant, but we may as well do it right this time around).

Check out the FormData and URLSearchParams bits of https://fetch.spec.whatwg.org/#body-mixin

Your current implementation looks a lot like what the fetch spec prescribes for URLSearchParams. I'm just learning this now too btw :) Seems like our currently included whatwg-url class handles URLSearchParams right, we just need to detect it as the bodySource and set the right headers automatically.

That's something we have not being doing quite right to be honest. We need to start looking in the fetch spec more to provide a better, more predictable, implementation.

If you want to convert your current PR to do the simple, small URLSearchParams fetch body switch case, that's probably more encouraging and shippable in a short amount of time :)

URLSearchParams

  • Set action to an action that runs the application/x-www-form-urlencoded serializer with object’s list.
  • Set Content-Type to application/x-www-form-urlencoded;charset=UTF-8.
  • Set source to object.

Copy link
Member

@jeromegn jeromegn left a comment

Choose a reason for hiding this comment

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

Never mind my previous comment, the FormData is on spec, except for how it's serialized in the body.

I believe the tests should use a Request and match a request precisely with the right serialization.

fly.http.respondWith(function(request) {
const formData = new FormData()
formData.append('foo', 'bar')
return new Response(formData)
Copy link
Member

Choose a reason for hiding this comment

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

I don't think an example with a Response is super relevant. I think FormData will be much more useful in requests.

FormData is now implemented in TypeScript and is API-complete (as seen
in https://developer.mozilla.org/en-US/docs/Web/API/FormData), minus the
ability to parse DOM tree, as FormData in Fly is more similar to the one
found in Service Workers API.
@mbyczkowski mbyczkowski merged commit e68dbdd into master Mar 2, 2018
@mbyczkowski mbyczkowski deleted the formdata-refactor branch March 2, 2018 00:45
@mbyczkowski mbyczkowski mentioned this pull request Mar 2, 2018
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