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

feat(back-matter): edit backmatter resources #768

Merged
merged 18 commits into from
Apr 17, 2023

Conversation

tuckerzp
Copy link
Contributor

@tuckerzp tuckerzp commented Apr 12, 2023

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

  1. For example, metadata.title updating metadata vs backmatter.resources[i].title updating all of backmatter.

@tuckerzp tuckerzp force-pushed the tuckerzp/edit-backmatter-resources branch from 25d7607 to 7815490 Compare April 12, 2023 18:04
@tuckerzp
Copy link
Contributor Author

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.

@kylelaker
Copy link
Contributor

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.

@tuckerzp tuckerzp force-pushed the tuckerzp/edit-backmatter-resources branch from 7815490 to 8d92880 Compare April 13, 2023 14:52
Copy link
Contributor

@kylelaker kylelaker left a 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.

Comment on lines 86 to 112
const backMatterDisplay = (resource: Resource) => (
<Grid item xs={3} key={resource.uuid}>
Copy link
Contributor

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
}

Copy link
Contributor Author

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/.eslintrc.json Show resolved Hide resolved
@tuckerzp tuckerzp force-pushed the tuckerzp/edit-backmatter-resources branch 2 times, most recently from adaa248 to f562c28 Compare April 13, 2023 16:38
@tuckerzp tuckerzp marked this pull request as ready for review April 13, 2023 16:57
@easy-dynamics-oscal-automation easy-dynamics-oscal-automation bot requested a review from a team April 13, 2023 16:57
@tuckerzp
Copy link
Contributor Author

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 .tsx that some files are not recognized as the same file.

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.

@easy-dynamics-oscal-automation easy-dynamics-oscal-automation bot requested a review from a team April 14, 2023 13:13
@easy-dynamics-oscal-automation easy-dynamics-oscal-automation bot requested a review from a team April 14, 2023 13:32
Comment on lines 111 to 136
<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}
/>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actual change here

Comment on lines 138 to 163
<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}
/>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

And here

@easy-dynamics-oscal-automation easy-dynamics-oscal-automation bot requested a review from a team April 14, 2023 17:09
Copy link
Contributor

@Bronstrom Bronstrom left a 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} />);
Copy link
Contributor

@Bronstrom Bronstrom Apr 14, 2023

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@kylelaker kylelaker Apr 14, 2023

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

Comment on lines 155 to 157
<Grid item>
<Typography variant={props.typographyVariant}>{props.value}</Typography>
</Grid>
Copy link
Contributor

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?

@easy-dynamics-oscal-automation easy-dynamics-oscal-automation bot requested a review from a team April 14, 2023 17:54
Copy link
Contributor

@kylelaker kylelaker left a 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.

@easy-dynamics-oscal-automation easy-dynamics-oscal-automation bot requested a review from a team April 17, 2023 15:07
Copy link
Contributor

@Bronstrom Bronstrom left a 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?

image

@Bronstrom
Copy link
Contributor

Also, one other difference I noticed when comparing backmatter resources between this branch and develop, is the DescriptionIcon (looks like a document in the right corner) is missing.

Before:

image

After:

image

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.
It is sadly needed here.
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.
@tuckerzp tuckerzp force-pushed the tuckerzp/edit-backmatter-resources branch from 1920130 to 43a9b8e Compare April 17, 2023 20:08
@tuckerzp
Copy link
Contributor Author

tuckerzp commented Apr 17, 2023

Although, it appears the JSON editor window is blank. Maybe during the refactoring process some properties were lost and not passed to OSCALEditableTextField?

I think #776 fixes that. develop just has not been merged in. From my understanding, the EditableTextField and the Drawer do not really interact. Should be good now!

the DescriptionIcon (looks like a document in the right corner) is missing.

Yeah it did not make sense to edit a little icon hover box. So description is now a text field.

@tuckerzp tuckerzp requested a review from Bronstrom April 17, 2023 20:10
@Bronstrom Bronstrom merged commit 6dc2a53 into develop Apr 17, 2023
5 checks passed
@Bronstrom Bronstrom deleted the tuckerzp/edit-backmatter-resources branch April 17, 2023 20:27
@kylelaker kylelaker added the enhancement New feature or request label Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants