fix(core): update getPublishDateFromRelease, add ScheduledRelease type #7754
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
pedrobonamin
commented
Nov 5, 2024
| @@ -64,28 +64,12 @@ export function getCreateVersionOrigin(documentId: string): VersionOriginTypes { | |||
| } | |||
|
|
|||
| /** @internal */ | |||
| export function getPublishDateFromRelease(release: ReleaseDocument): Date { | |||
| export function getPublishDateFromRelease(release: ScheduledRelease): Date { | |||
There was a problem hiding this comment.
Updated the type to ScheduledRelease to assert that a date will always be returned.
|
No changes to documentation |
|
Component Testing Report Updated Nov 5, 2024 12:47 PM (UTC) ✅ All Tests Passed -- expand for details
|
⚡️ Editor Performance ReportUpdated Tue, 05 Nov 2024 12:49:49 GMT
Detailed information🏠 Reference resultThe performance result of
🧪 Experiment resultThe performance result of this branch
📚 Glossary
|
pedrobonamin
force-pushed
the
corel-publish-date
branch
from
7dda639
to
a1a7b98
Compare
jordanl17
reviewed
Nov 5, 2024
| /** | ||
| * @internal | ||
| */ | ||
| export const isScheduledRelease = (release: ReleaseDocument): release is ScheduledRelease => |
There was a problem hiding this comment.
Hmm, the naming here is vague to me, because a scheduled release to me has state of scheduled or scheduling. This is like a prescheduled release, no? I wonder if we should introduce a name like intendedScheduledRelease?
There was a problem hiding this comment.
Yes, I think you are right, we need to find a better name for the intended schedule releases
jordanl17
reviewed
Nov 5, 2024
| @@ -170,7 +170,7 @@ export const GlobalPerspectiveMenuItem = forwardRef< | |||
| </Text> | |||
| {!isPublishedPerspective(release) && | |||
| release.metadata.releaseType !== 'undecided' && | |||
| (release.publishAt || release.metadata.intendedPublishAt) && ( | |||
There was a problem hiding this comment.
These aren't a like for like swap I don't think, since isScheduledRelease only looks at intendedPublishAt. I can't recall exactly but it might be worth verifying that when a scheduled release is actually scheduled, and it's possible to reconfirm the scheduled datetime, whether we also update the intendedPublishAt to reflex this too.
There was a problem hiding this comment.
Are we removing the intendedPublishAt when scheduling it?
It's confusing how close this names are.
Maybe we need to find a better name for the releaseType ="scheduled"
There was a problem hiding this comment.
I think we leave intendedPublishAt as whatever it was, and only persist this new date into publishAt via the schedule action. We should agree either to clear it or always keep it aligned. But of course the schedule action can also be triggered outwith studio, so guaranteeing they match isn't possible
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
We had two functions with similar names doing different things:
This PR removes the
getReleasePublishDatefunction and updatesgetPublishDateFromReleaseto always return a date and assert the correct type is passed.What to review
Testing
Notes for release