-
Notifications
You must be signed in to change notification settings - Fork 7
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
feature/Issue-97: Implement the Edit on GitHub component #111
Conversation
✅ Deploy Preview for super-tapioca-5987ce ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
4a797d9
to
a6fa1f0
Compare
1f7083a
to
933fd6a
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.
Nice, this is looking pretty good! Left some thoughts and feedback, let me know what you think. 🙏
function convertRouteToSubLink(route) { | ||
if (route === "/") return "index.md"; // root of diretory === index | ||
|
||
const DIRS = ["guides", "ecosystem", "getting-started", "hosting", "tutorials"]; |
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.
So I think its fine to just have a straight conversion here instead of hardcoding everything, since this will also extend to the Docs pages as well, and don't want to have to keep updating this every time we add it on a new page and all its sub routes.
I think it should be patched into this repo but there is also an id
property on each page which is a normalized output of the file name, that in hindsight might be a more useful way of converting from a route to a page path (this will get a little more organized in our new docs content coming soon to a greenwood website near you!). See the build output here as an example.
So basically, given this pages structure:
src/
pages/
index.html
guides/
index.md
something/
else.md
The IDs would come out as such
- src/pages/index.html -> index
- src/pages/guides/index.md -> guides-index
- src/pages/guides/something/else.md -> guides-something-else
So I think with that as more of a predictable pattern, you can always test if something is the root by the presence of index
at the end, which I think should make the conversions a bit easier.
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 gave this a shot, but it seems that the ID is not available, but maybe I'm using it incorrectly.
<app-edit-on-github route="${globalThis.page.id}"></app-edit-on-github>
Results in the attribute value being "${globalThis.page.id}", however, the route
does return the property value correctly.
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.
hmm, ok let me take a look. might be a missing patch set, and I can take a look at that Wednesday evening after out meeting. (I'll plan to do a fresh RC release in the next couple of days as part of #107 )
Or if you want to try with route
now, but it just might be a little trickier to get the conversion right. Will leave it up to you.
src/layouts/guides.html
Outdated
@@ -71,6 +76,17 @@ | |||
} | |||
} | |||
|
|||
.content-footer { |
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.
maybe we can target specifically with the tag name instead of a new class? I've been doing that with some of the other CEs on this page, so might make the most sense for consistency.
Also, same feedback here re: using Open Props where possible.
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.
Happy to make the change, but so to be clear, this class is applied to a wrapper around the <app-edit-on-github>
element. This is to provide a block-level container to the anchor tag and allow for the layout styles.
<body>
...
<div class="content-footer">
<app-edit-on-github />
</div>
</body>
Without the applied class, I'd apply styles like the following, which may impact future enhancements to the guides.html
layout if we were to add additional <div>
under .content-outlet
.
.content-outlet > div {
....
}
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.
Right, but I'm guessing why do we need the wrapper at all, if we just want to target the custom element anyway? I agree that making it sticky
and doing all the positioning from the parent makes sense, just not sure why we need to wrap at all? (For example, now I see now class at all on it, just an empty <div>
?)
Is it maybe because CEs are display:inline
by default, and the <div>
gives you a display:block
?
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.
Ah, gotcha. I used the wrapper as a means of positioning the anchor and giving it the margin. Let me remove it and give it a shot.
import "./edit-on-github.js"; | ||
import pages from "../../stories/mocks/graph.json"; | ||
|
||
export default { |
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.
similar comment here re: needing to actually mock out content data like this?
function convertRouteToSubLink(route) { | ||
if (route === "/") return "index.md"; // root of diretory === index | ||
|
||
const DIRS = ["guides", "ecosystem", "getting-started", "hosting", "tutorials"]; |
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.
hmm, ok let me take a look. might be a missing patch set, and I can take a look at that Wednesday evening after out meeting. (I'll plan to do a fresh RC release in the next couple of days as part of #107 )
Or if you want to try with route
now, but it just might be a little trickier to get the conversion right. Will leave it up to you.
src/layouts/guides.html
Outdated
@@ -71,6 +76,17 @@ | |||
} | |||
} | |||
|
|||
.content-footer { |
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.
Right, but I'm guessing why do we need the wrapper at all, if we just want to target the custom element anyway? I agree that making it sticky
and doing all the positioning from the parent makes sense, just not sure why we need to wrap at all? (For example, now I see now class at all on it, just an empty <div>
?)
Is it maybe because CEs are display:inline
by default, and the <div>
gives you a display:block
?
src/layouts/guides.html
Outdated
margin: var(--size-px-6) 0 var(--size-px-2) 0; | ||
} | ||
|
||
.content-outlet div[class*="edit-on-github"] a { |
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.
hmm, looks like we're piercing into the CE and styling the <a>
from the outside? Any reason this style can't be co-located within the module.css file as well?
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.
Cleaned this up, and moved to the module file.
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.
Sweet! Just made a small refactor to the route -> edit link conversion since we can rely on having a predictable IA (Information Architecture) and so with that constraint in place, this should now easily scale out to the Docs page as well, which should be pretty good for us for a while. All the tests and storybook still passed. 💯
Let me know your thoughts, otherwise will merge away soon. 👌
22d7eda
to
ebb27b1
Compare
Related Issue
Fix #97
Summary of Changes
<app-edit-on-github>
componentScreenshots
Screen.Recording.2024-10-14.at.13.25.38.mov
Screen.Recording.2024-10-14.at.13.26.18.mov
Todo