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

Route/Handler TypeScript normalization #2548

Merged
merged 8 commits into from
Jun 30, 2020
Merged

Route/Handler TypeScript normalization #2548

merged 8 commits into from
Jun 30, 2020

Conversation

jeffposnick
Copy link
Contributor

@jeffposnick jeffposnick commented Jun 19, 2020

R: @philipwalton

Fixes #2511

I am not 100% confident about the changes in this PR, especially as it relates to the new workbox-strategy code in v6. So your close attention and feedback is appreciated, @philipwalton. It will be good to shake this out during the v6 pre-releases to make sure nothing unexpected was done.

There are a number of JSDoc changes that need to be made along with these TypeScript changes, and I'll do them in a follow-up commit once we're happy with all the TypeScript types.

As part of this PR, I dropped the "shadow" types that were re-exported in workbox-routing/src/_types.ts and just refer to everything from a single source of truth, workbox-core/src/types.ts.

I tested this manually with some sample usage scenarios to confirm that tsc didn't flag any problems. All of the following worked fine:

registerRoute(
  /\.css$/,
  ({url}) => fetch(url.href),
);

const myHandler = ({request} : {request: Request}) => {
  return fetch(request);
};
registerRoute(
  ({url}) => url.pathname.endsWith('.js'),
  myHandler,
);

const networkFirst = new NetworkFirst();
registerRoute(
  '/abcd',
  networkFirst,
);

async function testHandler(request: Request) {
  const response = await networkFirst.handle({request});
  return response;
}
registerRoute(
  '/abcd',
  ({request}) => testHandler(request),
);

async function anotherTestHandler() {
  const response = await networkFirst.handle({request: '/blah'});
  return response;
}
registerRoute(
  '/abcd',
  anotherTestHandler,
);

const saveHandler = async ({url, event, params} : {
  url: URL, event: FetchEvent, params?: string[] | {},
}) => {
  console.log(url, event, params);
  return new Response('blah');
};
registerRoute(
  '/abcd',
  saveHandler,
);

* Options passed to a `ManualHandlerCallback` function.
*/
export interface ManualHandlerCallbackOptions {
request: Request | string;
event?: ExtendableEvent;
Copy link
Member

Choose a reason for hiding this comment

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

I believe we want to make this required in v6.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, right. We had talked about how using strategies manually outside of an event handler wasn't a great idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

One follow-up from that is that I need to change a lot of the parameter signatures in the PrecacheController class to mark the ExtendableEvent as being required. (That's probably a good thing, since using PrecacheController outside of an event sounds like a recipe for disaster.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This change also filters through to the MatchWrapperOptions and PutWrapperOptions interfaces, which now need to mark the event as required.

Copy link
Member

Choose a reason for hiding this comment

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

Not sure if you want to do this as part of this PR or a separate on, but there are many cases in our code where we've had to make an event optional in a type definition due to us not making it required in handlers (e.g. here). I did a in VSCode for event?:, and lots of cases come up (and there are probably others where the name "event" isn't used).

Also, there are cases where we're conditionally checking whether an event was passed (e.g. here), and it probably makes sense to remove those now.

How do you want to handle these?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, I can get those updated in this PR as well.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks, I went through and updated the corresponding jsdoc comments for a few that where missed (it was easier than going back and forth).

packages/workbox-core/src/types.ts Show resolved Hide resolved
packages/workbox-core/src/types.ts Outdated Show resolved Hide resolved
packages/workbox-routing/src/_types.ts Show resolved Hide resolved
packages/workbox-strategies/src/Strategy.ts Outdated Show resolved Hide resolved
packages/workbox-strategies/src/Strategy.ts Show resolved Hide resolved
packages/workbox-core/src/types.ts Show resolved Hide resolved
@jeffposnick
Copy link
Contributor Author

PTAL.

@googlebot
Copy link

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@jeffposnick
Copy link
Contributor Author

Okay! I think with your JSDoc updates, @philipwalton, and all the tests now passing, that's it for this PR.

If there's anything I left out, we can pick it up prior to the v6 release, but I'm merging for now.

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.

RouteHandlerCallbackOptions type is not conform to the doc
3 participants