Skip to content

Requesting JavaScript code review for new glossary popovers feature#4285

Closed
micshar92 wants to merge 12 commits intoopenboxes:feature/upgrade-to-grails-3.3.10from
micshar92:feature/upgrade-to-grails-3.3.10
Closed

Requesting JavaScript code review for new glossary popovers feature#4285
micshar92 wants to merge 12 commits intoopenboxes:feature/upgrade-to-grails-3.3.10from
micshar92:feature/upgrade-to-grails-3.3.10

Conversation

@micshar92
Copy link

Hi, everyone. I'm a junior technical writer volunteering here to beef up my portfolio. My background is in supply chain and data, and I want to prove my ability in APIs and code. That said, while I understand Python, SQL, and markup languages, JavaScript is proving existentially frustrating.

I'm requesting a JS code review for my glossary popovers feature. The idea is to have an <a> that when hovered over shows the term and definition (bootstrap popover title and content respectively) fetched from the glossary.json file. Wikipedia and the GitHub docs have something similar. Mine, however, show up like this:

Screenshot 2023-09-15 150825

Where bin_lTerm is supposed to be "bin location" and bin_lDef is supposed to be its definition, as I declare earlier in the JS. Here's an example of what I'm trying to do:

Screenshot 2023-09-16 113530

I might be on the right track, I just can't implement it correctly. Forgive me; I don't think I have a developer's brain.

My idea is:

  1. fetch() from a glossary.json file
  2. parse() the "title" and "definition", stringify(), store as variable
  3. call variable names in title and content of popover
  4. concatenate the "html" json string with "See also <a href="LINK">ARTICLE</a>" if the term links to a tutorial

But here are the problems I know of:

  1. Basically everything under the first block in POPOVER_TEST_PAGE.md is wrong.
  2. On the same document, why doesn't trigger="focus hover" work? It only works on click.
  3. Is my JSON structure right in glossary.json? I feel it's weird.
  4. In glossary.md, there are more probably-wrong fetch() functions. I'm also not sure about the concatenation for definitions that include an HTML link after it.

Please review / help. Thanks!

(Note: glossary.md is only populated with two sample terms as of now. I didn't want to write every term if the code for them was wrong.)

(Note 2: Once this is all correct, I'll get to work on finding terms across the site's guide pages and making them into the popover class. I think that's right.)

@jmiranda
Copy link
Member

@micshar92 Apologies for the delay. I probably won't have a chance to review this week but have requested a review by other developers. I will take a look next week.

Copy link
Contributor

@awalkowiak awalkowiak left a comment

Choose a reason for hiding this comment

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

@micshar92 the pages that you want to add are markdown, and you are trying to squeeze in html and jquery. I am not sure if this makes sense. Here is how you can achieve tooltips in markdown: BoostIO/BoostNote-Legacy#3579 (comment) (not a very good-looking version of tooltips, but works).

@awalkowiak
Copy link
Contributor

@micshar92 here is an example of "tooltip" for bin location:
markdown:

Lorem ipsum [bin location](## "Bin location
A location that designates a particular shelf, pallet position, or bin within a given zone in a given depot. For example, within Zone A, you may have a bin location for pharmacy items.")  something something

And how it looks like:
Lorem ipsum bin location something something

@micshar92
Copy link
Author

@awalkowiak I briefly considered the HTML <abbr> tag, which is basically the same thing with a little styling, but I thought it was subpar compared to the popover. Furthermore, if a definition changes or is removed, any page with that term would have to be updated, and that would quickly spiral into busy work and neglect ('cause ain't nobody got time for that). I know glossaries are not as important as regular docs, but the popover would in some cases have an internal link to another article for SEO benefits and sometimes reducing user frustration. Not so with a tooltip.

Still, I think it's best to populate the terms from an external source file. Markdown isn't built for huge amounts of code inside <script> tags, I know. I could make the glossary.md -> glossary.html, but I don't think it would change much. And a glossary page is very low traffic if it doesn't appear to be linked to other pages. It's a little like a sprig of parsley on a high-class dish.

Maybe I'm trying to do something too complex. It seems simple in theory to me, just hard to actually write the code. Is it actually impossible?

@awalkowiak
Copy link
Contributor

@micshar92 my example is still a link, but I have not used the link part in it, so it can be added. I am still not sure about using HTML and jQuery when the convention (other docs here in the project) is using a markdown.

@jmiranda what are your thoughts about this?

@micshar92
Copy link
Author

micshar92 commented Sep 25, 2023

@awalkowiak Yeah, you're right. Scrap the HTML idea.

As for the tooltip you showed... I can compromise on it. To me it's close-to-perfect, where the popover would be perfect. BUT maybe that's just me wanting my idea. It seems to carry the same functions, and it's drastically easier.

Not all of the terms have links, though. I'm thinking a simple style change: make the underline dotted for no-click terms, make all terms a regardless of type cadet blue. If my original idea is impossible, we now have a Plan B.

EDIT: Ah, wait. But if a term changes or is deleted or added, every page with that term would be instantly outdated. But maybe that's not a huge issue.

@micshar92
Copy link
Author

@awalkowiak @jmiranda How about this as a compromise: since I have little desire to learn JavaScript, and because I don't think a definition change will take that long to fix or be that hard (ctrl-F), let's drop the JSON/JavaScript idea. Instead, I'll go purely with HTML and SCSS.

I saw this screenshot in the recent release notes. I'll just copy the style you use here, and add <a> links when necessary. Simple. Easy.

ca574934750ebe59ea9c4ef8214f389a8b796a40

Tell me how you made these, and I'll use the same style for the terms, if it's possible.

@awalkowiak
Copy link
Contributor

@micshar92 these pages are made in React, and for these particular popups, we used this package: https://www.npmjs.com/package/react-tippy.

I have a question though - was the HTML + CSS requested here to be used instead of a simple markdown?

@micshar92
Copy link
Author

micshar92 commented Sep 29, 2023

@awalkowiak Markdown lets you use <html> and <style> tags for added flexibility: that's the HTML and SCSS I mean. I just think the terms need to be styled a little differently than a regular hyperlink, and the html is largely <dl>, <dt>, and <dd>: definition list, definition term, definition definition (SEO stuff). Terms are styled by just a few added lines to the main.scss file. The glossary page will still be Markdown.

That React package looks perfect. I'll use it.

@micshar92 micshar92 marked this pull request as draft October 4, 2023 20:18
@micshar92
Copy link
Author

(React doesn't appear to work with Markdown, but...)
@awalkowiak Hey! So I wrote this tooltip entirely in CSS. Here it is in action before hover:

Screenshot 2023-10-04 135234

... and after hover.

Untitled

...but then I realized there's no opportunity for me to use this. Why did I make this? Outside of the PiH pages or the wiki-- neither repo of which I can edit-- there are no terms to use a tooltip with on any page.

Anyway, I did still make the glossary page, but it's like the garnish on a fancy dish and I don't expect it to get much traffic. Oh well. If you choose to accept this super simple thing, here you go.

Looking forward to something more substantial, like what @jmiranda and I talked about in #4235 with Postman. OpenBoxes is directly in my writing niche, so I'll stick around.

@micshar92 micshar92 marked this pull request as ready for review October 4, 2023 22:13
@jmiranda
Copy link
Member

jmiranda commented Oct 5, 2023

Looks good @micshar92.

FWIW, the following mkdocs plugin (https://github.com/AngryMane/mkdocs-glossary-plugin) might be useful. It doesn't solve the problem but gets us close.

When a page is loaded, the mkdocs glossary plugin will iterate over the glossary terms defined in the glossary directory

image

and attempt to find those glossary terms within the page. When it finds one, it annotates (wraps) the term with a link to the glossary term.

image

And that link leads us to an individual page with the glossary term definition.

image

This isn't exactly what we want but it gets us part of the way by allowing us to

  1. Define glossary terms
  2. Find and replace glossary terms within the DOM

So we can either extend the plugin to allow for a link vs tooltip option. This might be more difficult than I'm imagining but I thought this was cool.

The other bummer about this plugin is that we need to maintain a separate file per glossary term instead of a JSON file with everything defined. But it solves the one problem that I expected to be difficult i.e. automating the application of glossary terms in the DOM. So perhaps it buys us enough to work with.

@jmiranda
Copy link
Member

jmiranda commented Oct 5, 2023

The mkdocs Annotations plugin (https://squidfunk.github.io/mkdocs-material/reference/annotations/) also looks promising but requires the annotations to be included in the source markdown content.

image

Not sure if mkdocs has a pre-process/post-process hooks, but if so we could potentially rewrite the markdown content during the deployment process OR perhaps use the two plugins together.

@jmiranda
Copy link
Member

jmiranda commented Oct 5, 2023

Here's another potential solution.
squidfunk/mkdocs-material#1919

Copy link
Member

@jmiranda jmiranda left a comment

Choose a reason for hiding this comment

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

LGTM just remove the <br/> tags and we can merge this.

<dt>ABC Analysis class</dt>
<dd>This class system categorizes products based on their impact on cost. Products in Class A contribute to the majority of costs because you use and buy them most often. You buy Class B products more infrequently. Class C items are not high value and do not need many follow-ups.</dd>

<br>
Copy link
Member

@jmiranda jmiranda Oct 6, 2023

Choose a reason for hiding this comment

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

You can remove the <br/> elements as we can add space using CSS.

Copy link
Author

Choose a reason for hiding this comment

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

Done. You're right: in my typography notes, I wrote down long ago to never use carriage returns. Looks like I forgot this time. Good lesson to learn before making that mistake for a big company.

Copy link
Author

Choose a reason for hiding this comment

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

@jmiranda Whoops didn't @ you. Anyway, it's done.

@micshar92 micshar92 closed this by deleting the head repository Oct 18, 2023
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.

3 participants