refactor: move tags handling from cache-handler module to dedicated tags-handler to allow for reuse #2872
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ags-handler to allow for reuse
📊 Package size report 0.03%↑
Unchanged files
🤖 This report was automatically generated by pkg-size-action |
mrstork
previously approved these changes
Apr 25, 2025
| ): Promise<number | null> { | ||
| const tagManifest = await cacheStore.get<TagManifest>(tag, 'tagManifest.get') | ||
| if (!tagManifest) { | ||
| return null |
There was a problem hiding this comment.
If we wanted, we could return a number here as well and simplify the return type of this function to just Promise<number>. Perhaps -1?
There was a problem hiding this comment.
pros & cons
returning a number may simplify types and possibly remove the need to do specific null checking, but I think it's actually better to return non-number here exactly to force consumer of this function to consider what should be done when there is no value so it forces to take a second how to handle scenario if there is no tag manifest as this should prevent bugs that are result of oversight if someone would assume there is always a value here
Next.js use cache handler wants to return 0 in cases like that - https://github.com/vercel/next.js/blob/071e31705f4451bdeb8ada4126a0da9c49d11761/packages/next/src/server/lib/cache-handlers/types.ts#L102-L108 so maybe we should follow this, but because this is used not just for new cache handler I'd prefer more verbose handling to ensure that consumers handling don't have potentially incompatible oversights
… be specific to response cache handler soon
…he directly to ensure uniform handling and logging
mrstork
previously approved these changes
Apr 25, 2025
…o-op, so need to track it more carefully
mrstork
approved these changes
Apr 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This splits off changes needed for #2862 to be more self contained and to make things easier to review in chunks.
This moves tags handling to dedicated module instead of handling all of it in existing cache handler. On it's own this should increase seperation and readability as existing cache handler already is pretty complex and handle many concerns so this just moves one of those concerns out and also sets things up so tags handling can be reused for
use cachehandlersTests
Existing tests using tags and tag purges should still pass. There should be no functional changes happening.
Relevant links (GitHub issues, etc.) or a picture of cute animal
Part of FRB-1405