refactor(conditional-page-build): explicitly persist status of generated html files #29473
Conversation
gatsbot
bot
added
the
status: triage needed
pieh
added
topic: SSG*
and removed
status: triage needed
pieh
force-pushed
the
refactor-current-cpb
branch
2 times, most recently
from
a617fb8
to
ed40a7d
Compare
pieh
force-pushed
the
refactor-current-cpb
branch
4 times, most recently
from
05ce91f
to
5ea1e47
Compare
pieh
force-pushed
the
refactor-current-cpb
branch
from
5ea1e47
to
10dba80
Compare
pieh
force-pushed
the
refactor-current-cpb
branch
3 times, most recently
from
d6a05c4
to
d9f226d
Compare
Co-authored-by: Vladimir Razuvaev <vladimir.razuvaev@gmail.com>
…e issues with creating pretty error message with codeframes etc
pieh
force-pushed
the
no-fs-in-ssr-no-static-queries-in-ssr-bundle
branch
from
0c83fdc
to
aac9d30
Compare
pieh
force-pushed
the
refactor-current-cpb
branch
from
d9f226d
to
acb7d0e
Compare
|
|
||
| const FLAG_DIRTY_CLEARED_CACHE = 0b0000001 | ||
| const FLAG_DIRTY_NEW_PAGE = 0b0000010 | ||
| const FLAG_DIRTY_PAGE_QUERY_CHANGED = 0b0000100 // TODO: this need to be PAGE_DATA and not PAGE_QUERY, but requires some shuffling |
There was a problem hiding this comment.
👍 Also noticed that PAGE_QUERY is a bit confusing name for what it actually is.
There was a problem hiding this comment.
#29498 is one that addresses TODO here. This PR is largely 1 to 1 refactor of current stuff and introduction of html reducer and tried to avoid making more changes than just to keep what we currently track so far
| // we can't just clear the cache here - we want to keep track of pages, so we mark them all as "deleted" | ||
| // if they are recreated "isDeleted" flag will be removed | ||
| state.browserCompilationHash = `` | ||
| state.trackedHtmlFiles.forEach(htmlFile => { | ||
| htmlFile.isDeleted = true | ||
| // there was a change somewhere, so just in case we mark those files are dirty as well | ||
| htmlFile.dirty |= FLAG_DIRTY_CLEARED_CACHE | ||
| }) |
There was a problem hiding this comment.
What is the downside of just clearing the cache here? Is it only that we will re-build all HTML files? Or also that there could be some stale files left as a result?
I am not sure if it makes sense to have special handling for this case as it makes things more complicated in general. Ideally, files should be the derived artifact of our state but not the other way around?
There was a problem hiding this comment.
With code as-is - this is to remove .html / page-data files that are not recreated later on.
Ideally, files should be the derived artifact of our state but not the other way around?
I'm not sure if this is the case of the other way around - I don't exactly use individual files and work backward to create state from them - instead this is
We will blow away our state, but there are will be some files created from state we had before and we will need to keep part of that state to know what we need to clean up. If we want to start completely clean, we will need to do expensive
publicdeletion (or traverse public dir and delete some files)
Not the hill I will die on, but we do have opportunity to use previous state to do targetted deletions instead of brute force deletions ;)
Description
This moves
GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGESpage query result changes and webpack compilation hash changes tracking from "transient" to more explicit tracking.It achieves few things:
conditional-page-builds.mdchanges):gatsby developsessions in-betweengatsby buildsGATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGESspecific cli switches (--log-pagesand--write-to-file)PR builds on #29396
[ch23311]
[ch23313]
[ch23488]
[ch23535]