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

Add Tags to Catalog Criteria #10007

Merged
merged 23 commits into from May 10, 2024
Merged

Add Tags to Catalog Criteria #10007

merged 23 commits into from May 10, 2024

Conversation

thsparks
Copy link
Contributor

@thsparks thsparks commented May 7, 2024

This change adds tags to criteria in the catalog. The schema is setup to support criteria having multiple tags, but for now we only adjust our display based on the first tag. This may change if we add more criteria and start using more granular tags, but it's not necessary given the current catalog.

If a criterion doesn't have any tags, it gets assigned an "Other" tag. Currently, all visible catalog criteria have tags, so the other tag is never shown.

Initially, the first tag in the catalog is expanded, but the tool remembers which tags the user expands/collapses and preserves those for the next time the catalog is opened.

I made a few adjustments to the accordion display to support this change:

  1. A flag to allow multiple items to be expanded
  2. The ability to specify an initial "open" item set
  3. The optional ability to specify ids for each item (to support number 2)

Upload target is here, but since it's looking at production docs, everything is just placed into the "Other" category for now: https://makecode.microbit.org/app/13ea77ed2e1da12176c4c12a9907981375709c43-71c65280c6--eval

Screenshots (from localhost with updated docs)
image
image
image
image

Fixes microsoft/pxt-microbit#5597

const mappedChildren = React.Children.toArray(children);
const isExpanded = expanded === panelId;
const isExpanded = expanded.indexOf(panelId) != -1;
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this need to be !== instead of !=?

type ClearExpanded = {
type: "CLEAR_EXPANDED";
};

type Action = SetExpanded | ClearExpanded;
type Action = SetExpanded | RemoveExpanded | ClearExpanded;
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we keeping ClearExpanded for a feature that allows a user to collapse all expanded categories?

Copy link
Contributor Author

@thsparks thsparks May 8, 2024

Choose a reason for hiding this comment

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

Yeah, I just thought it might be useful later on. I can remove it.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm actually on board with keeping this in for the component's sake. I think it's a very common use case that a user wants to collapse all the expanded categories when there's too much going on, I just wanted to check in that that was the reason why it was left in.

Copy link
Contributor Author

@thsparks thsparks May 9, 2024

Choose a reason for hiding this comment

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

I already removed it 😉 but should be easy to re-add if someone needs it down the road

export async function removeExpandedCatalogTagAsync(tag: string) {
let expandedTags = getExpandedCatalogTags();
if (!expandedTags) {
await setExpandedCatalogTags([]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is it needed that we set the expanded tags to an empty list if getExpandedCatalogTags() returns undefined?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If someone is trying to remove a saved expanded tag but there were none saved to begin with, it's a pretty bizarre scenario to begin with, but I decided to switch it over to an empty list (to save state as "all categories collapsed") rather than undefined, which is mostly just the initial "nothing has happened yet" state. It's pretty arbitrary handling of a shouldn't-ever-happen edge case.

teachertool/src/components/CatalogOverlay.tsx Outdated Show resolved Hide resolved

const tags = Object.keys(criteriaGroupedByTag);
if (tags.length === 0) {
return null;
Copy link
Contributor

Choose a reason for hiding this comment

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

To clarify, does this mean that the overlay will be empty if there were no tags defined?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. It'd mean there were no criteria, since every criteria (once loaded into state) should have at least one tag. Should never happen, but better this than some random error, imo.

Copy link
Contributor

Choose a reason for hiding this comment

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

Gotcha, makes sense. Maybe we should log something, too? Makes sense that it should never happen, but I feel like if there was a blank overlay and someone looked at the console and no problems were reported, it would feel very buggy. Although I'm guessing there should be other errors in the console if that were to happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added error log

}
}

export async function addExandedCatalogTagAsync(tag: string) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
export async function addExandedCatalogTagAsync(tag: string) {
export async function addExpandedCatalogTagAsync(tag: string) {

let expandedTags = getExpandedCatalogTags();
if (!expandedTags) {
// If we haven't saved an expanded set, default expand the first one.
addExandedCatalogTagAsync(tags[0]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
addExandedCatalogTagAsync(tags[0]);
addExpandedCatalogTagAsync(tags[0]);

<Accordion.Header>{tag}</Accordion.Header>
<Accordion.Panel>
{criteriaGroupedByTag[tag].map(c => {
const existingInstanceCount = teacherTool.checklist.criteria.filter(
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering if we should break out these catalog entries into its own component like CatalogOverlayEntry or something like that to keep the accordion area clean.

@@ -77,7 +90,7 @@
.action-indicators {
position: relative;
padding: 0 1rem 0 0;
width: 3rem;
width: 3rem; // Match common-accordion-chevron
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this comment needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's a nice reminder if someone ever changes it, they should consider changing it there too (which may or may not look good depending on the new value, up to the engineer at that point). Could go and do a whole var for it but that seemed like overkill to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, I'm not sure if that warrants a comment, personally. I feel like there is a lot of styling that is made in order to match with styling elsewhere, and leaving that up to experimentation is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I were the engineer making the change, I would appreciate the comment because it's the kind of thing I'd otherwise miss :) But if you feel very strongly I can remove it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nope, don't feel strongly; fine to keep it in.

type: "REMOVE_EXPANDED";
id: string;
};

type ClearExpanded = {
Copy link
Member

Choose a reason for hiding this comment

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

is this used anymore? can probably be removed

return `accordion-item-${tag}`;
}

function onTagExpandToggled(tag: string, expanded: boolean) {
Copy link
Member

Choose a reason for hiding this comment

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

this being async seems dangerous. looking at the implementation below of these two functions, it seems like hammering on this button could cause some issues with multiple copies of the same tag being added to the state

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah true...I'll just remove the async stuff. Most of our local storage stuff isn't async anyway.

return (
c.template && (
<Button
id={`criteria_${c.id}`}
Copy link
Member

Choose a reason for hiding this comment

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

is this id used anywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, I don't think it is, actually. I'll remove it.

Copy link
Contributor

@srietkerk srietkerk left a comment

Choose a reason for hiding this comment

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

Looks great!

@thsparks thsparks merged commit 1b14c18 into master May 10, 2024
6 checks passed
@thsparks thsparks deleted the thsparks/teachertool/tags branch May 10, 2024 01:35
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.

Rule catalog organization
4 participants