As new frontend features are developed by the Threat Management team we should be consciously choosing to use components from the Pajamas design system.
Key Result: ...
Actions to achieve this goal:
@gitlab-org/secure/threat-insights-frontend-team will track any scenarios where they were unable to use Pajamas design components in their MRs in this issue.
Any community contribution MRs will be reviewed to ensure Pajamas design components are used & cases where they are unable to follow this convention will be documented in this issue.
That's basically it. There's a list of Pajamas components listed here https://design.gitlab.com/components/status. Some are still in the process of being integrated into the product (see related OKR regarding our team contributing to this migration). When building new elements in the UI we should first check if there's a component available for use.
@andyvolpe - is there any other details we should be considering here?
We have some createFlash calls in our security dashboards. Is migrating them to gl-alert (which is pajamas component) inline with the expectations?
Edit Sorry my bad, the signature of createFlash has changed. That's why there is a deprecatedCreateFlash function. I guess it has nothing to do with Pajamas.
To be clear: converting existing code is not part of this KR (but we should make an effort to do so whenever we find the need). The goal of this issue is to ensure that any new code introduced this quarter uses Pajamas components when they are available.
Wayne Haberchanged title from WIP [FY21-Q3 KR] 100% of new Threat Management features added in Q3 use pajamas components to [FY21-Q3 KR] 100% of new Threat Management features added in Q3 use pajamas components
changed title from WIP [FY21-Q3 KR] 100% of new Threat Management features added in Q3 use pajamas components to [FY21-Q3 KR] 100% of new Threat Management features added in Q3 use pajamas components
@lkerr Can you add more detail on these updates? For example, have there been no opportunities to use pajamas components on new features? Or have there been opportunities to do so and we haven't been able to take advantage of them? (or something else).
@whaber - I will work with the @gitlab-org/threat-management/frontend team to provide a more detailed updates going forward. My last comment reflected that there had been no reports of MRs relying on legacy or custom (ie. non-Pajamas) components for any of our new development.
I'm still researching an automated way to measure the results of this OKR, until now it's been a conversation happening during 1:1s & a general request of the team to call out any MRs that use non-Pajamas components in our Threat Management area of the codebase. If I am able to determine a more accurate way to identify newly introduced cases where Pajamas components were not used, I will update the results of this OKR to reflect that. I'm also taking a way the lesson of having a plan for measuring the OKR documented before it's agreed to.
Lindsay Kerrchanged the descriptionCompare with previous version