-
Notifications
You must be signed in to change notification settings - Fork 585
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
Add Tags to Catalog Criteria #10007
Conversation
const mappedChildren = React.Children.toArray(children); | ||
const isExpanded = expanded === panelId; | ||
const isExpanded = expanded.indexOf(panelId) != -1; |
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.
Does this need to be !==
instead of !=
?
type ClearExpanded = { | ||
type: "CLEAR_EXPANDED"; | ||
}; | ||
|
||
type Action = SetExpanded | ClearExpanded; | ||
type Action = SetExpanded | RemoveExpanded | ClearExpanded; |
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.
Are we keeping ClearExpanded
for a feature that allows a user to collapse all expanded categories?
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.
Yeah, I just thought it might be useful later on. I can remove it.
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'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.
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 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([]); |
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 is it needed that we set the expanded tags to an empty list if getExpandedCatalogTags()
returns undefined?
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.
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.
|
||
const tags = Object.keys(criteriaGroupedByTag); | ||
if (tags.length === 0) { | ||
return null; |
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.
To clarify, does this mean that the overlay will be empty if there were no tags defined?
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.
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.
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.
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?
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.
Added error log
} | ||
} | ||
|
||
export async function addExandedCatalogTagAsync(tag: string) { |
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.
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]); |
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.
addExandedCatalogTagAsync(tags[0]); | |
addExpandedCatalogTagAsync(tags[0]); |
<Accordion.Header>{tag}</Accordion.Header> | ||
<Accordion.Panel> | ||
{criteriaGroupedByTag[tag].map(c => { | ||
const existingInstanceCount = teacherTool.checklist.criteria.filter( |
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'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 |
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.
Is this comment needed?
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 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.
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, 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.
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.
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.
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.
Nope, don't feel strongly; fine to keep it in.
type: "REMOVE_EXPANDED"; | ||
id: string; | ||
}; | ||
|
||
type ClearExpanded = { |
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.
is this used anymore? can probably be removed
return `accordion-item-${tag}`; | ||
} | ||
|
||
function onTagExpandToggled(tag: string, expanded: boolean) { |
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 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
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 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}`} |
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.
is this id used anywhere?
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, I don't think it is, actually. I'll remove it.
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.
Looks great!
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:
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)
Fixes microsoft/pxt-microbit#5597