-
Notifications
You must be signed in to change notification settings - Fork 44
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 facts modal/code viewer & detail drawer tab #1057
Conversation
c48ad3d
to
d415d01
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #1057 +/- ##
==========================================
- Coverage 47.07% 47.06% -0.01%
==========================================
Files 177 177
Lines 4412 4417 +5
Branches 980 983 +3
==========================================
+ Hits 2077 2079 +2
- Misses 2321 2324 +3
Partials 14 14
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
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.
Just a couple things.
|
||
export type Fact = { | ||
name: string; | ||
data: any; |
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 was going to suggest we replace any
with unknown
here to prevent any issues with code assuming it's a string (JSON.stringify won't care what it is), but since we're going to revisit this to support structured facts it's probably fine to leave it as-is (and it stands out as something to be fixed anyway which is maybe good)
{filteredFacts.map((fact) => { | ||
return ( | ||
<div> | ||
<Button |
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 flat list of link-buttons with no real layout aside from line breaks really bothers me for some reason, but that's a design issue. Maybe we can revisit this with Justin. I think even just a compact table with one unlabeled column, or maybe a DataList
(https://www.patternfly.org/v4/components/data-list), something to make it look less plain. Outside the scope of this PR though, just thinking out loud.
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.
Opened an issue for this & linked in the description.
language={Language.json} | ||
height="450px" | ||
code={JSON.stringify(fact.data)} |
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.
The design calls for displaying this in YAML rather than JSON right? Since we already have the js-yaml
package installed we could import yaml from 'js-yaml';
and then use yaml.dump(fact.data)
instead of JSON.stringify(fact.data)
, and use Language.yaml
instead of Language.json
. I think that should be sufficient, although we may want to wrap the yaml.dump
in a try-catch by lifting this code out into a variable. I suppose the API always gives us JSON and all JSON can be stringified to YAML so maybe that's 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.
Ah, looking at the docs we can avoid this ever throwing an exception by using the skipInvalid
option:
code={yaml.dump(fact.data, { skipInvalid: true })}
client/src/app/queries/facts.ts
Outdated
const { data, isLoading, error, refetch } = useQuery( | ||
[FactsQueryKey, applicationID], | ||
{ | ||
queryFn: async () => await getFacts(applicationID), |
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 noticed this recently in a lot of our queries (and I am guilty of copying it), but we don't actually need async/await for these queryFns if all we're doing is calling a function that already returns a promise. We may want to simplify all these at some point to:
queryFn: () => getFacts(applicationID)
however this is harmless as-is, just a nitpick.
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.
Really just some style questions
<CodeEditor | ||
isReadOnly | ||
isDarkTheme | ||
isLineNumbersVisible | ||
language={Language.json} | ||
height="450px" | ||
code={JSON.stringify(fact.data)} | ||
/> |
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 is basically cheating! PF has some nice stuff integrated.
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.
It took a little bit of configuring in https://github.com/konveyor/tackle2-ui/pull/966/files, but not much! now we just have it for wherever we want 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.
Now it would be really good to get code splitting working so the main app bundle isn't too huge.
PS - I know how to get it working, just haven't worked it up into a skinny PR yet.
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.
We would love the help with code splitting! It's something I've never really taken the time to figure out.
client/src/app/api/rest.ts
Outdated
|
||
// Facts | ||
|
||
export const getFacts = (id: number | string | 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.
The other query functions have an explicit return type Promise<?>. Does it make sense to add one here?
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 one may fall under the same category as this comment. I am unsure how to type this unstructured fact that is just a json/yaml object that hasn't been parsed yet.
</div> | ||
); | ||
})} | ||
{selectedFactForDetailModal ? ( |
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.
You use the form {renderCondition && (<element />)}
form in other places, why ternary here?
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 was trying to match the style we used in issue-affected-files-table for consistency's sake.
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.
We're not consistent about it in this repo, but I've always tried to favor the ternary because &&
can fall back to falsy values that still render something (like 0
). https://kentcdodds.com/blog/use-ternaries-rather-than-and-and-in-jsx
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
26e084d
to
657f20f
Compare
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.
LGTM assuming we revisit the Fact/UnstructuredFact types in a followup.
Notes: This does not cover the filter/sort logic for facts based on sources. There is no mock data available from the api for this yet, but we will be required to collate the fact sources ourselves on the UI side based on the fact keys returned from the hub. konveyor/tackle2-hub#396 for more info on how the api will look.
TODO: #1061
TODO: How should we type facts with an unknown data type?