-
Notifications
You must be signed in to change notification settings - Fork 11
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
feat(back-matter): edit backmatter resources #768
Conversation
25d7607
to
7815490
Compare
Tests are failing because I changed how description is displayed. Should be an easy fix, I will wait until we discuss approach before I fix it. |
Great stuff! This isn't quite as thorough of a rework as I'd like to have seen overall but it gets things working for this task. What we still need is a written description of how to use this framework; can you please write some documentation? I don't care whether it's docs on those lower-level functions or docs in Markdown written somewhere but we need documentation on how this works because we have a ton of upcoming editing tasks. |
packages/oscal-react-library/src/components/OSCALEditableFieldActions.js
Outdated
Show resolved
Hide resolved
7815490
to
8d92880
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.
Hey! I know that some of these asks go a little beyond your ticket but I am hopeful that we can do a little more cleanup while we're in here to improve the type checking and composability of some of these components. I'd even like to see us be able to export
BackMatterDisplay
when this is done.
If some of these are too complicated to do now, please be very explicit about the errors that tsc
or eslint
gives you and we can track them as tech debt to fix later.
Thank you so much for all your work on this so far! I'd approve as-is but I think it'd be good to use this to set a good example for what we're looking for in some of our refactoring as we incrementally adopt TypeScript. Especially since there's at least one bug in this code today that wasn't so obvious until now.
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
const backMatterDisplay = (resource: Resource) => ( | ||
<Grid item xs={3} key={resource.uuid}> |
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.
For composability, rather than being a nested function, this almost feels like it should be its own component in the root of the document...
interface EditableFieldProps {
isEditable?: boolean;
onFieldSave?: (...args: any[]) => void;
partialRestData?: Record<string, any>;
}
interface BackMatterResourceProps extends EditableFieldProps {
resource: Resource;
}
function BackMatterResource(props: BackMatterResourceProps): ReactElement {
//... the body of this function
}
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 have tried to do this and it is not much cleaner. I think this is becuase you can't really edit a resource title without it being generally aware of all other resources. It may be that I am just missing something, so I will push it and see what everyone thinks.
packages/oscal-react-library/src/components/OSCALEditableFieldActions.test.tsx
Outdated
Show resolved
Hide resolved
adaa248
to
f562c28
Compare
As a note to reviewers, the diff has gotten a bit nasty here. While there is really not much change, there was enough with switching to Feel free to comment on specific lines or I can provide a bit more context on the major changes if that is helpful. Hopefully between the pr comment and some of my commit messages, what is happening is clear enough. |
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
packages/oscal-react-library/src/components/OSCALEditableTextField.tsx
Outdated
Show resolved
Hide resolved
<OSCALEditableTextField | ||
fieldName="title" | ||
canEdit={props.isEditable} | ||
editedField={props.isEditable ? [objectKey, "back-matter", "resources"] : null} | ||
editedValue={props.backMatter?.resources} | ||
editedValueId={resource.uuid} | ||
onFieldSave={props.onFieldSave} | ||
partialRestData={ | ||
props.isEditable | ||
? { | ||
[objectKey]: { | ||
uuid: props.partialRestData?.[objectKey].uuid, | ||
"back-matter": props.backMatter, | ||
}, | ||
} | ||
: null | ||
} | ||
value={resource.title} | ||
/> |
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.
Actual change here
<OSCALEditableTextField | ||
fieldName="description" | ||
canEdit={props.isEditable} | ||
editedField={props.isEditable ? [objectKey, "back-matter", "resources"] : null} | ||
editedValue={props.backMatter?.resources} | ||
editedValueId={resource.uuid} | ||
onFieldSave={props.onFieldSave} | ||
partialRestData={ | ||
props.isEditable | ||
? { | ||
[objectKey]: { | ||
uuid: props.partialRestData?.[objectKey].uuid, | ||
"back-matter": props.backMatter, | ||
}, | ||
} | ||
: null | ||
} | ||
value={resource.description} | ||
/> |
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.
And here
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
packages/oscal-react-library/src/components/OSCALBackMatter.test.tsx
Outdated
Show resolved
Hide resolved
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
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.
Looking good so far!
renderer(); | ||
describe("OSCAL Backmatter", () => { | ||
test("displays resource title", () => { | ||
render(<OSCALBackMatter backMatter={backMatterTestData} parentUrl={parentUrlTestData} />); |
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 back matter test data is duplicated throughout the tests. Is there any reason to avoid having a renderer function?
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 that for tests being explicit and a bit repetitive is a good thing. I want to be able to look at a test and understand what is happening without having to look through a bunch of code.
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 agree 100% with @tuckerzp. This is a small enough difference that I think it's valuable to just make the call. Additional indirection is not useful here and is actually less helpful for debugging.
I am very much opposed to these styles of "renderer()" functions.
What is the alternative? Calling renderer()
over and over? It's still one line repeated many times. Not sure the juice is worth the squeeze.
In fact, I'd argue that our tests should not be using the same data and the same parameters every time; and that would discourage some magic function that solves the problem of repetition. We should solve it by it not existing in the first place
<Grid item> | ||
<Typography variant={props.typographyVariant}>{props.value}</Typography> | ||
</Grid> |
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 how much value this Grid
adds. Would removing the Grid
and just having props.value
within the Typography
support the same cause? Or could we use a Stack
instead?
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 amazing! Thank you SO MUCH for the TypeScript refactoring and for fixing up other issues as you were in here! It looks like we not only added this feature but fixed a few subtle bugs. I also appreciate you highlighting where the changes actually happened -- that was helpful in this large diff.
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.
Overall, this looks great! I love all the refactoring choices made to improve the overall structure of editing and the implementations made with TypeScript.
Although, it appears the JSON editor window is blank. Maybe during the refactoring process some properties were lost and not passed to OSCALEditableTextField
?
packages/oscal-react-library/src/components/OSCALBackMatter.tsx
Outdated
Show resolved
Hide resolved
This adds basic editing functionality for backmatter resource titles and descriptions. Our original editing functionality made some assumptions that made implementing this tricky. Namely, we assumed that the text field we are updating is the direct child of the field we are sending a PATCH request for. For example, `metadata.title` updating `metadata` vs `backmatter.resources[i].title` updating all of `backmatter`. As you can see in the code, the way we handle editing is a bit hacky and naive. We most likely want to revisit this and redo a lot of that code. This would not be an insignificant change, hence it being pushed for now. These changes make editing at least work for now so that our other editing tasks are no longer blocked.
This attempts to document how one would go about adding editing to a text field. This **does not** mean this is the best way to actually do this. To clear up the blocker of editing, this at least makes it possible to edit. We will want to revisit editing at some point in the future.
Switching to .tsx helped highlight some flaws with the tests. The major difference is that we are no longer testing things in such a wack way. Each component tests itself. The only exception is EditableFieldActions, as that component does not make much sense existing on it's own.
Rather than documenting these variables in an outer .md file, this documents each variable and provides some examples.
1920130
to
43a9b8e
Compare
I think #776 fixes that.
Yeah it did not make sense to edit a little icon hover box. So |
This adds basic editing functionality for backmatter resource
titles and descriptions.
Our original editing functionality made some assumptions that made
implementing this tricky. Namely, we assumed that the text field we are
updating is the direct child of the field we are sending a PATCH request
for. 1
As you can see in the code, the way we handle editing is a bit hacky and
naive. We most likely want to revisit this and redo a lot of that code.
This would not be an insignificant change, hence it being pushed for
now. These changes make editing at least work for now so that our other
editing tasks are no longer blocked.
closes EasyDynamics/comply0-private#68
Footnotes
For example,
metadata.title
updatingmetadata
vsbackmatter.resources[i].title
updating all ofbackmatter
. ↩