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

✨ Fix missing archetype flow pieces #1368

Merged

Conversation

ibolton336
Copy link
Member

@ibolton336 ibolton336 commented Sep 15, 2023

Closes #1298 #1278 #1332 #1324

  • Adjusts routes for archetype assessment flow vs application assessment flow
  • Creates a hook for looking up app or archetype based on their ID to avoid conditional hook calls.
  • Wire up create assessment override check
Screenshot 2023-09-18 at 12 33 20 PM -Drive assessment wizard from assessment rather than questionnaire
  • With this PR, assessment flow is fully working for apps and archetypes against the hub outstanding PR.

@ibolton336 ibolton336 force-pushed the archetype-assessment-integration branch from 35629ae to 725e53d Compare September 15, 2023 16:34
@codecov
Copy link

codecov bot commented Sep 15, 2023

Codecov Report

Patch coverage: 63.15% and project coverage change: +0.05% 🎉

Comparison is base (063e16a) 41.43% compared to head (666141c) 41.48%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1368      +/-   ##
==========================================
+ Coverage   41.43%   41.48%   +0.05%     
==========================================
  Files         137      137              
  Lines        4279     4288       +9     
  Branches     1026     1034       +8     
==========================================
+ Hits         1773     1779       +6     
- Misses       2418     2420       +2     
- Partials       88       89       +1     
Flag Coverage Δ
client 41.48% <63.15%> (+0.05%) ⬆️
server ∅ <ø> (∅)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed Coverage Δ
client/src/app/api/models.ts 100.00% <ø> (ø)
client/src/app/queries/applications.ts 47.54% <50.00%> (ø)
client/src/app/queries/assessments.ts 26.82% <50.00%> (ø)
client/src/app/queries/reviews.ts 20.75% <50.00%> (ø)
client/src/app/components/ConfirmDialog.tsx 75.00% <57.14%> (-15.00%) ⬇️
...ents/custom-wizard-footer/custom-wizard-footer.tsx 91.66% <75.00%> (+0.75%) ⬆️
client/src/app/Paths.ts 100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ibolton336 ibolton336 marked this pull request as ready for review September 15, 2023 17:15
@ibolton336 ibolton336 force-pushed the archetype-assessment-integration branch from d01d581 to fa5d61a Compare September 15, 2023 17:18
Copy link
Collaborator

@mturley mturley left a comment

Choose a reason for hiding this comment

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

A couple of nitpicks here that may be a pain to address. I'm fine leaving them if you want, but wanted to express them anyway to see if you agree.

}) => {
const { t } = useTranslation();

const isArchetype = location.pathname.includes("/archetypes/");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hm, what's the reason for changing this from a prop? If we ever needed to show the questionnaire content for an archetype outside the archetypes page (as a modal or something) this would be an issue. Not that we ever need to be able to do that necessarily, it's probably fine, just curious

Copy link
Member Author

Choose a reason for hiding this comment

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

I changed everything to be driven off of the location path because I was seeing some undefined props on hard navigation to some of the routes. Maybe that would be better handled by redirects. Some more testing is probably warranted here.

Copy link
Member

Choose a reason for hiding this comment

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

If you made the isArchetype prop required and provided a default value like isArchetype = false, then you would not see an undefined value.

Alternatively, you could use the useLocation or useRouteMatch hook from react-router to be a bit more robust in the isArchetype check.


console.log("archetype", archetype);
console.log("archetype or app data", data);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we still need the console.log here?

Copy link
Member

@sjd78 sjd78 left a comment

Choose a reason for hiding this comment

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

Another way to organize the component would be to have an ApplicationAssessmentSummary and an ArchetypeAssessmentSummary. Then have those just wrap AssessmentSummary with a bunch of constants (isArchetype, title, urlPath1, urlPath2, etc). The child components would need to have access to those props (just passing them down is ok), but they wouldn't need to know how to select them.

For things like:

          <Text component="p">
            {isArchetype ? archetype?.name : application?.name}
          </Text>

The name can just come from a EntityWithName kind of type:

  ... // like in `items-select.tsx`:
  EntityWithName extends { name?: string };

  ...
  entityWithName: EntityWithName

  ...
          <Text component="p">{entityWithName?.name}</Text>

Then any archetype or application could be given as the entity.

None of that is a blocker though.

}) => {
const { t } = useTranslation();

const isArchetype = location.pathname.includes("/archetypes/");
Copy link
Member

Choose a reason for hiding this comment

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

If you made the isArchetype prop required and provided a default value like isArchetype = false, then you would not see an undefined value.

Alternatively, you could use the useLocation or useRouteMatch hook from react-router to be a bit more robust in the isArchetype check.

>
Assessment
</Link>
{isArchetype ? (
Copy link
Member

Choose a reason for hiding this comment

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

This could be push into the to prop instead of containing the full tag

@@ -19,38 +20,38 @@ export const AssessmentPageHeader: React.FC<AssessmentPageHeaderProps> = ({
}) => {
const { t } = useTranslation();
const history = useHistory();
const isArchetype = location.pathname.includes("/archetypes/");
Copy link
Member

Choose a reason for hiding this comment

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

This has been repeated enough times that it is a good candidate to create a hook for....

const isArchetype = useIsArchetypeFromLocation();

Copy link
Member Author

Choose a reason for hiding this comment

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

All good ideas. Will work on refactoring.

@ibolton336
Copy link
Member Author

ibolton336 commented Sep 18, 2023

Another way to organize the component would be to have an ApplicationAssessmentSummary and an ArchetypeAssessmentSummary. Then have those just wrap AssessmentSummary with a bunch of constants (isArchetype, title, urlPath1, urlPath2, etc). The child components would need to have access to those props (just passing them down is ok), but they wouldn't need to know how to select them.

For things like:

          <Text component="p">
            {isArchetype ? archetype?.name : application?.name}
          </Text>

The name can just come from a EntityWithName kind of type:

  ... // like in `items-select.tsx`:
  EntityWithName extends { name?: string };

  ...
  entityWithName: EntityWithName

  ...
          <Text component="p">{entityWithName?.name}</Text>

Then any archetype or application could be given as the entity.

None of that is a blocker though.

I like this pattern. I think it is a candidate for a refactor post feature freeze but am hesitant to attempt this with there being a third archetype/application agnostic usage for this summary component in the assessment-management-settings page.

@ibolton336 ibolton336 force-pushed the archetype-assessment-integration branch from 41a205f to 8632697 Compare September 19, 2023 14:40
Copy link
Collaborator

@mturley mturley left a comment

Choose a reason for hiding this comment

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

One last nitpick here @ibolton336 . I do think there is some more room for cleanup here but I don't think it needs to block feature freeze. We should maybe open a tech debt issue to make sure we follow up.

Comment on lines 6 to 12
const [isArchetype, setIsArchetype] = useState(
location.pathname.includes("/archetypes/")
);

useEffect(() => {
setIsArchetype(location.pathname.includes("/archetypes/"));
}, [location.pathname]);
Copy link
Collaborator

Choose a reason for hiding this comment

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

You don't need the state or the effect here because all they are doing is duplicating the new value from useLocation() when it causes a re-render. If that useEffect is being triggered, it means we already have an updated location.pathname value in scope (because useLocation watches for it to change and re-renders), and we can just return that directly instead of putting it in state. So I think this whole hook can be rewritten as:

const useIsArchetype = () => useLocation().pathname.includes("/archetypes/");

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated - thanks!

Copy link
Member

@sjd78 sjd78 left a comment

Choose a reason for hiding this comment

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

Just blocked on the return on the for loop, otherwise looks good.

Signed-off-by: ibolton336 <ibolton@redhat.com>

Drive isArchetype off of location in case of hard nav

Signed-off-by: ibolton336 <ibolton@redhat.com>

Remove redundant query

Signed-off-by: ibolton336 <ibolton@redhat.com>

Modify confirm dialog to include archetype assessment override alert

Only show matching assessments for each entity type

Update assessment override to use fetchassessment by archetype id approach

wire up create assessment on confirm

Use hook for isArchetype

update test file

Update logic for take assessment

Wire discard assessment/review back in

Fix hook and add override placeholder

Signed-off-by: ibolton336 <ibolton@redhat.com>
@ibolton336 ibolton336 force-pushed the archetype-assessment-integration branch from 67ebb16 to 666141c Compare September 19, 2023 21:21
Copy link
Member

@sjd78 sjd78 left a comment

Choose a reason for hiding this comment

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

LGTM

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.

Check existing archetypes when starting an app assessment
3 participants