-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New sandcastle title and dirty state tracking #12794
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
base: sandcastle-v2
Are you sure you want to change the base?
Conversation
Thank you for the pull request, @jjspace! ✅ We can confirm we have a CLA on file for you. |
c0ea093
to
6341032
Compare
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 @jjspace! A few questions and branding-related comments.
@@ -4,7 +4,7 @@ | |||
<meta charset="UTF-8" /> | |||
<link rel="icon" type="image/svg+xml" href="/favicon.ico" /> | |||
<meta name="viewport" content="width=device-width, initial-scale=1.0" /> | |||
<title>Sandcastle Reborn</title> | |||
<title>Cesium Sandcastle</title> |
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.
<title>Cesium Sandcastle</title> | |
<title>CesiumJS Sandcastle</title> |
I think, technically speaking, this should be the branding?
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.
Possibly? I was just matching what the current Sandcastle uses
return window.confirm( | ||
"You have unsaved changes. Are you sure you want to navigate away from this demo?", | ||
); |
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.
This is totally up-to-par with what we had before, but what do you think of propagating the current sandcastle to local storage or similar?
The goal would to be to persist state, like what happens when you reload a GitHub tab with an in-progress comment. Or maybe a slightly different workflow, like what happens if you leave and come back to https://geojson.io/.
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.
what do you think of propagating the current sandcastle to local storage or similar?
This (or similar) has been requested often and I do really want to find some solution to try and prevent lost work. However I think it should be a separate effort, this PR just tries to match the functionality of the existing sandcastle. This is already on the running task list but further down for lower priority.happy to re-evaluate if you think it's a "must have" before release.
My current thought is not to make it truly persist every page load but offer a "saved state" that we can suggest the user reload like jsfiddle does

envString = `${host.replace("localhost:", "")} `; | ||
} | ||
|
||
const baseTitle = "Cesium Sandcastle"; |
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.
const baseTitle = "Cesium Sandcastle"; | |
const baseTitle = "CesiumJS Sandcastle"; |
or possibly even just the following due to all the other info?
const baseTitle = "Cesium Sandcastle"; | |
const baseTitle = "Sandcastle"; |
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 want this to match whatever title we pick for the base page so the specific sandcastle title is just prepended. I'm open to dropping down to just "Sandcastle" but I wasn't sure about dropping the branding
if (title !== "") { | ||
document.title = `${envString}${title}${dirtyIndicator} | ${baseTitle}`; | ||
} else { | ||
document.title = `${envString}${baseTitle}`; | ||
} |
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.
- Why shouldn't we show the dirty indicator on named sandcastles?
- Assuming we can, couldn't we simplify this to thew following?
if (title !== "") { | |
document.title = `${envString}${title}${dirtyIndicator} | ${baseTitle}`; | |
} else { | |
document.title = `${envString}${baseTitle}`; | |
} | |
document.title = `${envString}${title}${dirtyIndicator} | ${baseTitle}`; |
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.
This check makes sure that we only add the title and the |
to the page title when there's actually a title to prepend in front of the bar. The page starts with an empty title ""
in state when it initially loads because we don't know what it will be yet.
If a specific gallery demo is not loaded then we replace it with "New Sandcastle" thus providing a title and it will show the dirty indicator.
@ggetz no updates yet but I responded to all your comments if you wanna take another look. |
Description
*
to the page titleMerge after #12755 as this is based on the UI work in there
Issue number and link
Part of #12566
Testing plan
npm run dev
in the sandcastle package ornpm run build-sandcastle
andnpm start
from the project root*
Author checklist
CONTRIBUTORS.md
CHANGES.md
with a short summary of my change