so that consumers can pass one or more icon buttons which or other actions like an icon button or checkbox. So like, I just would relate this to that work possibly. Yeah.
Yeah, I think we did have that linked somehow. I don't know if it made a link for this issue. Let me check. It did not make it onto this issue. So if somebody wants to link that if that is documented somewhere in here, too, so that way, everything's kind of connected that would be wonderful. Because yes, just a generic way of saying we want actions to be able to exist within the header of a card, and one of those actions can be select this. That sounds like a great way to implement this. Yeah,
just to be a composable solution. It doesn't factor into the like actual data table interaction stuff. But it would be it'll be compatible. Yeah.
Yeah, exactly. Exactly. Cool.
So I'm understanding kind of the architecture of this though. You were describing the checkbox being like in the code beside the card. If we have a pattern that was more similar to this later, that action was a sub component of the card. So would there be some sort of like card event that would like go backwards up the React chain to trigger what it is like? Is this a checkbox? Do we want to set it up so that the checkbox is inside the card but whenever you click it, it still selects the whole thing, or at this point.
Good right now, this is what we've got right the checkboxes next to the card and it shows we select the whole card when we select it. So that's the current behavior, because it is really based on the table view, where we're selecting the entire row. So that makes sense there, but it feels a little bit weirder when we've got it just sitting next to a card. It's less clear that this is there. So being able to put that inside the card and have the same behavior from a UX standpoint is what we're hoping for. One just to make sure that that's that's clear.
Yeah, another consideration just on the current state here is that there is a prop that the consumer can do to control which sides that checkbox is on. So that progression to like if that's a concern for like, the position of those actions in the current image cap as well.
Yeah, yeah, that could be a cool thing is being able to the position of those left or right based on a prop as well.
Yeah, but I guess, like in terms of how it interacts with data table specifically, that's a data table prop but to Caleb's point like if the if we're going to the solution of like passing it as a node to the card, like as a child to the card component. Then like, you can't necessarily control the positioning of that with just the data table prop alone, right? Like you'd have to figure out that interaction somehow because the card component itself is like a custom card. Pass consumer. Yeah,
yeah. Okay.
All right. This is just my last question here. Sorry. I'm back with a bunch of questions. I apparently. So what was the reason that we wanted the checkbox to be there? Like why not just have a card that when you click on it, it has some obvious selection pattern.
Um, that is, that is another option. I think the big thing is that this is using the data table the checkbox, we don't really have an option to hide that the only way to select something within the data table is by clicking the checkbox. Okay. Yeah, like I can verify that that's the case. Let me make sure. Oh,
yeah. Because you'd have to, you'd have to account for the UI of a list and have a hard correct because it's the data table.
So because with the data table here, just clicking a line in the table or clicking anywhere in the card, doesn't do anything, clicking the checkbox selects it. Okay, so the idea would be, even if we wanted to make it so the whole clicking the card was selecting it that that would be a change as well, right? That would be another possible option. But I think the checkbox was a something that already works in the table and card view. So just having it so it's still there seemed reasonable. Couple
questions. This is just for the data table, correct?
Yes, this is for the data table card view. That is the specific thing now where in components that makes it that would be kind of an implementation detail, and we could see, like, if nothing else, we could make it so this is completely optional to have within a card and if you wanted it to be selectable with a checkbox, you could do that outside of a data table, but I would not expect that to be something that we have to do
so. Yeah. And just to go back to I saw there was actually another a UI element with the three dots on the mock is yeah. Is is that just for marketing purposes, is that another element we'll have to account for?
I think that's for marketing purposes. Okay. The big thing that they wanted was the checkbox. I'm not sure what the other actions they were hoping to put in the three dots were but that's something that we should be able to do within the header. That should be easier than the selecting with a checkbox part. If nothing else, yeah, the Yeah, the day dots is just a drop down menu that was completed using the header element of the card. The checkbox isn't part of the card. So that's why Yeah. modification. Perfect. Cool. So it sounds like trying to move forward with this is something we can do. I will look into what an implementation might look like. Try to get at least a draft PR up showing something and then we have code to talk about which makes it easier than just having everything the possibilities and designs. Awesome. Anyone else? Anything on this or can we move on to the next item?
Yeah, just the thought about the accessibility concern around like if the card itself is interactive, like he probably wouldn't want to put the checkbox inside of there. So like just the interaction with the these clickable prop on the card component just might be good to like include some usage guideline around that somewhere in the box. Okay,
yeah, I will make a note about usage guideline for is Yeah.
clickable and checkbox in card to prevent what Jeff mentioned, about focus about within focus.
And I guess that same question kind of goes to just like not data table specific but just like having actions in the card, image cap itself, as well.
Yeah. Okay. Cool. That sounds great.
Cool. Then the next thing I had was about the country field, auto suggest component in authen. Because with the new changes to the auto suggest component, we should be able to simplify this implementation quite a bit. But it looks like we need to take into account the error state outside of the component itself. So right now, the updated auto suggest component has a way to say these are the requirements I require there to be a value in here I require that value to exist from the drop down and then it will be able to show an error message based on those So implementing that was pretty easy. But there is also this external stuff where we are handling the error, which kind of goes beyond the scope of the auto suggest component itself. So I was wondering if we need to update the auto stress component to have an error states that then consuming applications can see in some way, because right now everything is just being handled externally to the component. This is still using the old version of the auto suggest component where all validation is being run outside of the component, as well as Yeah, there are some some other things that are happening with like, parsing the string that is being displayed and then getting a country code because we don't have stuff with actual keys and values. It's just the display value. So a lot of that can be cleaned up. But the main thing that is happening here is specific times and we are handling an error change. And that is not something that the auto suggests component rework has accounted for. So I'm just wondering if anybody has ideas on like, the best way to get that error state out of the auto stress component. With three work in mind
i realized i i clicked into something and did not actually share that tab. So let me
I wasn't even supposed to be sharing something there. Yeah,
yeah. Okay. So here. We have the handle error change stuff. And if we look into the country field, we have all of this validation that is happening in the country field component that is like external to the auto suggest component. Most of this can be moved out of here. So with the new auto suggest component, we would just say that value is required and selection is required. And then we would have on change, and that would get us all of the information about do we actually have a selection. And then for all of these options that we have here, we just add an ID in here with the country code key and then we can get that directly instead of needing to go through this external validator because if we actually go into validate country field, we'll see what's happening here is we're going through and finding the country based on the display value and then getting a country code for that and it's just be Agron externally instead of just being able to get the country code directly as a key from the auditor just components and we should be able to rip that part out. A lot of this is going to be much simpler. And I'm excited to be able to simplify this implementation. But it looks like handling the error change outside of just showing an error message on the auto suggests component is something that needs to happen here. And so being able to say, Hey, I'm an auto suggests component in error. State is some and this is the error state that I'm in seems to be something that we need to handle that I had not accounted for because this had not showed up on the list of MSPs that was using it when I was building this out. Do you have any thoughts on how to how to do that would be greatly appreciated. Otherwise, I can just start digging into stuff. I only noticed this because I was upgrading things to be able to upgrade versions of Paragon after the edX to Open edX scope change. So yeah.
So at a high level, is it kind of just an issue of controlled versus non controlled components? In a sense?
Yeah, yeah. Because before it was something where the error state is completely being handled externally here, like here, we've got a form control feedback. We're setting the error completely outside of it. Whereas now, the components itself, we can just say, Hey, this is the error message that you show when you're in this error state. And then hey, this is the error message. That you show when you're in this error state. But we don't have a good way to get as a consumer. Hey, are you in an error state? So I was thinking maybe, yeah, yeah. To kind
of force it to be in that error state, rather than the component deciding when it should be embarrassed that? Well,
we do have a way to force it into an error state. We have custom validation as well. That is an option. What I didn't think about was, do we have a way to then use the built in validation and then read from that in a way other than just seeing it as a user that it is an error state? So yeah, um, do
we have any like callbacks or anything like that like an on error callback?
We don't we can do that. That would be an option. Anything that is just attitude I am all for because that keeps us as a minor version bump and that's great.
The call back appreciate is something that we do like for example, like on selected like it's a common pattern. But yeah, like how you deal with when it gets out of the error state like what happens then?
We could do on error state change. Yeah,
yep. Yeah. Seems reasonable to me. Okay,
add a callback for on error state change. That sounds great. Cool. I will make a note of that as a way forward and call back. On Air state change, do suggest, yeah, that'll be perfect. And then that will be separate from the standard on change, which is what we'll be using instead of on selected because now we get like a full object from on change saying if we have user entered text as well as if that matches the selection and then also a ID associated with that. So cool. That's everything I had. That's great. We've got a good path forward there. Let me get back to the agenda and refresh see if anybody's added anything.
Doesn't look like it. Does anybody have any last minute things to add here?
Brian, do you think it's worth getting some feedback from the group here around the possible release strategy for design tokens that you're chatting about?
Oh, yeah, that's a great idea. Um, so for design tokens. We were let me add that to the agenda. Let me go ahead and go into edit mode. So yeah, for design tokens, what we were discussing was right now we've got the Alpha brand, the alpha branch, right? So that has all this stuff in design tokens. And that has been something that we've needed to keep in sync with master on a regular basis. And it's also something that's a little bit hard to actually use. When you're trying to have a continuing application use that. So upgrading to use design tokens and supporting alpha with pure dependencies ends up causing issues kind of across the board. In general, it's not the cleanest thing to try to consume Paragon from an alpha release. So one of the thoughts was, let's get to a point where we're happy enough with design tokens to say this is out of alpha, and then release it yet that into a new breaking change version of Paragon. Right now we're on 22 That would make design tokens 23. If we have another breaking change before then then it would be 24 versus 23 instead of 23 versus 22. And then any new work is happening on the design tokens branch or on the design on master which would have all of the design token stuff in there. But we would maintain a pre designed tokens branch that would be for where we do security updates, bug fixes. And then if there is anything that's like a specific feature where the upgrading an MFP to use design tokens is just a huge task and it would make more sense to backport something then we can do back boards in but it would kind of move away from needing to keep things in sync. And instead we would just be how to we would have a legacy supported version pre designed tokens that we would be able to work forward from as well as a all new work would be happening in the design tokens world and that would kind of get people accustomed to that being how things are working going forward. This kind of goes in line with trying to push to actually move things to design tokens. The goal is to at least have some MFDs moved over by the time we release redwood. That is a optimistic goal but it is a goal and then by the time we release sumac The goal is to have all of the MFPs that are at least included in tutor MFP to be upgraded to use design tokens completely. So yeah, that's the that's kind of the idea. And I think that getting people working in design tokens and not needing to think everything into the Alpha branch and just have that maintenance burden would really speed up the would speed up the process of getting everything moved over. So yeah, any thoughts also, thank you so much for taking notes there.
Just another plug, I guess that we do have some open source community members that are backporting already to previous open index named releases, and we're trying to prevent that from continuing. So this would be in support of that by making that path to use tokens much more straightforward and easy for those consumers that are already using them to.
Yeah, absolutely. Absolutely.
Yeah, I guess my only concern is just around like if there's a new component that gets merged on the 23 that a consuming team that you're you kind of already believe is best, but just like if that upgrade is heavy, just like where do we draw the line on what we do backport and what we don't like having that a little bit more like a line drawn in the sand I guess, might be helpful. Rather than being like a super case by case basis every single time.
Yeah, I think in general, I will default to Why can't you upgrade to use the design tokens version? Like that's kind of the question that the team that wants a backport would have to answer. And at that point, it would kind of be case by case but in general, the
concrete answer for the enterprise admin portal MFE right now like that still uses some deprecated Paragon components like the table component for some of our components and that's been blocked on designing input that we haven't had the resources to get input on.
Yeah, yeah. So that's a very fair answer is we are still relying on deprecated components that don't exist in the design tokens world and we'd need design input to be able to replace those deprecated components. Okay, cool. That's a good answer. Right. So I guess we can use that as a starting point of this is an example that would be a reason to backport but yeah, in general, yeah. I guess deprecated relying on deprecated components without a path away from using those deprecated components is a good yes, we can backport because of that general answer, in my opinion.
Yeah. And luckily we did invest in I believe it was through the Fed bomb team. They did go through a lot of the NFS like a year and a half ago or so to try to move as many of the deprecated components off. So there's PRs open in all the repos like even the ones that are blocked there's PRs open for moving off the deprecated components anyway, so it's a half step towards it anyways, yeah.
Moving away from deprecated components is absolutely something that should be happening and it'll just be part of the upgrade process. The one
other thought that the deprecated components is that they've been deprecated for basically since they've been deprecated, which is like three to four years ago at this point. To remove them from Paragon. Yeah, absolutely.
Absolutely. Yeah, I mean, I think it makes sense that we still have those deprecated components. And if we start to think of 22 as legacy, then we still have those deprecated components in there because this is legacy but yeah, yeah, I think I'm really happy that those are actually gone. The Alpha branch and that we will start not needing to support them. anymore when people move over to design tokens. Okay. Anybody else have thoughts on this? Anybody excited to see design tokens? Get out of alpha? Anybody? Have Reese? Have something that they're scared about what design tokens that we need to make sure makes it onto the checklist of things before this gets out? general thoughts on moving away from it being an alpha branch?
This is like mostly answered by the conversation that we've been having this whole time but with the marketplace team that I'm on building a new project from scratch. I should be communicating saying that these are stable and we need to use them right like that's the right messaging is not like this is alpha we should probably use it I should be saying like this is definitely sufficiently stable like we need to use this. Is that fair?
I I get the impression it is yeah. I would like someone that's been more in the actual code base of the olive branch to be able to confirm that. But yeah. I feel like if I was going to make a new RFP, I would want to be using the version of stuff.
Right? No, absolutely. Yeah,
I can just be for what record game was was doing recently. They've been opening a lot of like low hanging fruit PRs around bug fixes that we've been. They've been identifying around, like actually trying to upgrade the to alpha and various admin fees. So there are like small little style fixes that might crop up during the upgrade but nothing major it should happen like it should be largely parody with like what we have today. Save a few little discrepancies here and there. That can be
awesome. Yeah, it might actually make sense to look into doing like a release candidate strategy. And so that way, we can do some testing with stuff in release candidate mode. So could you another thing to consider
what it's worth the Alpha branch was like a half step towards like the release channel like strategy, but obviously a constant taking that as far as it could have. Yeah.
All right. I'm cool. I'm glad that we talked about design tokens release strategy stuff. That was cool.
Yeah, I just wanted to come back to something that Caleb mentioned. Just this is more I guess, and to the marketplace concerns, but just one call out. I believe the edx.org is pointing on like changing the Paragon theme a little bit for edx.org on top of like, like, having it be a distinct theme from the brand edx.org package so that it can be changed colors in isolation from all VMFS so that we don't have to change like the branding and all that for edx.org alongside all the NFE is all in one go. So for Caleb I guess I'm speaking to here is like I'm I guess when developing that new theme, it might be worth starting with the tokens support rather than starting with the SCSS support and then migrating.
Yeah, yeah, no, I'll share that. My guess is is that appetite for creating a new theme has been diminished, but I could be wrong about that.
That was just the last conversation I had gave about it was recommendation was to create the new theme.
Cool sounds good. We're
kind of getting to that spot. Yeah, I'd love to have a conversation about that, because I think we kind of had questions on the design side. So maybe I can I'll throw some time on your calendar. Yeah. Literally just slacking, Amy about that as we kind of, you know, approach this next step. So I'll also put on your calendar for next couple of days.
Okay, sounds great. I look forward to it. Alright
cool. Well, thanks, everybody. Unless there's any last minute things that we want to add. I think it's been a very productive working group meeting. So thanks for showing up. Thanks, Brian. Thanks. Absolutely. See everybody. Yeah, have a good day. Bye. Bye. Bye.
