Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat(next-drupal): next revalidate options #784
feat(next-drupal): next revalidate options #784
Changes from 2 commits
1679890
7675920
9d81656
2601b53
0c3270e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Popping in on this one based on my ongoing review of #787 Specifically: https://github.com/chapter-three/next-drupal/pull/787/files#diff-5b898e58a9c454bff499b9401f4794981861fc3d8870905f57e8082c4e24b6f5
The notes about NextFetchRequestConfig caused me to take a closer look at the types to confirm that this would actually be possible in the state of the codebase that the Docs PR is in. I believe it is possible to pass options like
next: { revalidate: 3600 }
- ourFetchOptions
interface extends Next'sRequestInit
which does have thenext
property that accepts options forrevalidate
andtags
. That was a mouthful. Here's what the types look like:Our fetch options:
Next Types:
Based on reading that code, I'd expect this to already be supported without this
JsonApiWithNextFetchOptions
type. But my guess is that you saw otherwise when actually working with this.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.
Thanks for bring this up @backlineint. Looking at this again, I noticed that in "our" functions (
getResource
,createResource
, etc) the options parameter is of typeJsonApiOptions
and notFetchOptions
.JsonApiOptions
doesn't contain many of the properties thatFetchOptions
has. We should take a closer look at this and probably reworkJsonApiOptions
to include all/some ofFetchOptions
.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.
It's becoming a bit problematic not being able to pass cache options with next-drupal API requests.
For example:
revalidate
.revalidateTag
cache tag invalidation.What needs doing to progress this feature?
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.
Agreed @davidwhthomas - working on setting some time aside this week to try to help move this one forward.
While I'm here, one thing that either needs to be added here, or handled in a follow up issue is adding the api route for tag invalidation to the basic (app router) starter.
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.
Took another look at this, and I think the problem is that the next-drupal-pages class also uses JsonApiOptions. Adding fetchOptions to JsonApiOptions won't make sense for the pages router. Don't doubt that we could still refine these types, but also don't see an easy path to that in this PR.
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.
I tested locally and confirmed that we don't need to add
JsonApiWithNextFetchOptions
here.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.
You're right. I removed this from the FetchOptions type.