Skip to content
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

Redirects for dev mode short links #465

Merged
merged 4 commits into from
Sep 1, 2021
Merged

Redirects for dev mode short links #465

merged 4 commits into from
Sep 1, 2021

Conversation

aomarks
Copy link
Member

@aomarks aomarks commented Sep 1, 2021

Adds a https://lit.dev/msg/<code> redirect for all warnings logged by Lit's dev mode.

Half of lit/lit#2078. Other half is at lit/lit#2119.

@github-actions
Copy link

github-actions bot commented Sep 1, 2021

A live preview of this PR will be available at the URL(s) below.
The latest URL will be appended to this comment on each push.
Each build takes ~5-10 minutes, and will 404 until finished.

https://pr465-57420cb---lit-dev-5ftespv5na-uc.a.run.app/
https://pr465-cadae46---lit-dev-5ftespv5na-uc.a.run.app/

Copy link
Contributor

@AndrewJakubowicz AndrewJakubowicz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really great and a huge ergonomic improvement using Lit. I tried out manually some short urls:

These work great:

Query params are not handled but can probably punt since we have control of the short urls:

https://pr465-57420cb---lit-dev-5ftespv5na-uc.a.run.app/msg/removed-api?mods=doesquerywork

Is there a way to test the redirect so we don't accidentally break a link. For example updating a content heading could change the heading id and break the fragment redirect.

path = path.replace(/\/+$/, '/');
}
path = pageRedirects.get(path) ?? path;
if (path !== ctx.path) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Elegant!

Especially like how this check handles the three different 301 cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, but... can we add a comment? :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment about how it's to flatten redirect chains so we don't actually serve a chain of them.

@arthurevans
Copy link
Contributor

Looks good to me. I hadn't though of the redirect testing that @AndrewJakubowicz mentioned, but I think we'll (at a minimum) need to add comments to each of the docs sections where these links land, so we don't accidentally break the intended association between the current URL and the answer we're looking for (for example, when refactoring one section into two). I opened #467 for that, because it doesn't seem like it needs to be part of this PR.

path = path.replace(/\/+$/, '/');
}
path = pageRedirects.get(path) ?? path;
if (path !== ctx.path) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, but... can we add a comment? :)

@aomarks
Copy link
Member Author

aomarks commented Sep 1, 2021

Query params are not handled but can probably punt since we have control of the short urls:

https://pr465-57420cb---lit-dev-5ftespv5na-uc.a.run.app/msg/removed-api?mods=doesquerywork

Is there a way to test the redirect so we don't accidentally break a link. For example updating a content heading could change the heading id and break the fragment redirect.

Good idea. It would be nice if we could use the link checker we already have for this, but it doesn't support checking for anchors (see stevenvachon/broken-link-checker#108 -- understandable since it would require DOM parsing). I've written a little custom script to do this, will send it in a followup PR.

Looks good to me. I hadn't though of the redirect testing that @AndrewJakubowicz mentioned, but I think we'll (at a minimum) need to add comments to each of the docs sections where these links land, so we don't accidentally break the intended association between the current URL and the answer we're looking for (for example, when refactoring one section into two). I opened #467 for that, because it doesn't seem like it needs to be part of this PR.

I think a checker is worthwhile, and then we won't need any comments since CI will break.

@aomarks aomarks merged commit c90e4e3 into main Sep 1, 2021
@aomarks aomarks deleted the dev-msg-short-links branch September 1, 2021 17:52
aomarks added a commit to lit/lit that referenced this pull request Sep 1, 2021
Adds a See https://lit.dev/msg/<code> for more information. string to all warnings logged by Lit's dev mode.

Half of #2078. Other half is at lit/lit.dev#465.
@aomarks
Copy link
Member Author

aomarks commented Sep 1, 2021

Good idea. It would be nice if we could use the link checker we already have for this, but it doesn't support checking for anchors (see stevenvachon/broken-link-checker#108 -- understandable since it would require DOM parsing). I've written a little custom script to do this, will send it in a followup PR.

Done in #468

@arthurevans
Copy link
Contributor

Link checker is 🔥. I'd still like to add comments to at least the sections in the main docs, because those sections serve multiple purposes. We could (and probably should) add a more specific section on class field shadowing, say, or change-during-update, but in doing so we probably wouldn't remove the existing anchor, so the link wouldn't break, even though the relevant content might have moved to another section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants