-
Notifications
You must be signed in to change notification settings - Fork 1
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
Paginate Operations Form #269
Conversation
384365c
to
352bfe1
Compare
970efda
to
1dcca7d
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.
The form is looking gorgeous! I did end up with a couple more questions. I wrote comments but if walkthrough is easier, happy to do that too.
A few general things (some could probably be tech debt or aren't a priority):
- The status comes out with an underscore:
- The breadcrumb is showing the form step as an ID:
- Not sure if this is part of your ticket, but when there are errors about missing fields, it looks like there should be a message:
- the step circles get distorted at different screen sizes:
- It looks like pending operations should be readonly. Operation 3 from the mock data is readonly, but I could edit the one I made: https://www.loom.com/share/7c67dd95a1df4416a6e9bf9bb5c19af3
- At mobile sizes, the input ends up on top of the label:
# set the operation status to 'pending' on update | ||
operation.status = "Pending" | ||
# set the operation status to 'pending' on update | ||
if submit == "true": |
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.
What does submit true/false mean? Like if it's the entire form submission vs one of the steps?
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.
On the final step we set ?submit=true
so that we can set the status to pending
. We want the status to stay as not_registered
unless we are submitting.
@@ -90,10 +90,10 @@ def test_post_new_operation(self, client): | |||
) | |||
post_response = client.post(self.endpoint, content_type=content_type_json, data=mock_operation.json()) | |||
assert post_response.status_code == 200 | |||
assert post_response.json() == {"name": "Springfield Nuclear Power Plant"} | |||
assert post_response.json() == {"name": "Springfield Nuclear Power Plant", "id": 2} |
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.
how do we know that id is 2?
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.
Not a Django testing expert but that is the id that is being created and returned in this test. I assume a test above it is creating "id: 1"
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 don't think it's safe to assume the correct value is what the test returns. If you just run that single test do you get id=1?
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's not 100% guaranteed that this id
value will always be 2, because the order in which unit tests are run can vary. In this test case we don't care what the specific valud of id
is, we just want to make sure that the id key-value pair is returning in the json, so I'd recommend replacing this with something like
assert post_response.json().get('name') == 'Springfield...'
assert post_response.json().get('id') is not None
@@ -173,7 +173,7 @@ def test_put_operation_not_verified_when_not_registered(self, client): | |||
def test_put_operation_update_status_invalid_data(self, client): | |||
def send_put_invalid_data(): | |||
operation = baker.make(Operation) | |||
assert operation.status == Operation.Statuses.PENDING | |||
assert operation.status == Operation.Statuses.NOT_REGISTERED |
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.
Why do we need to check the default status so often?
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 not sure, I updated the original tests which were checking the default status and kept it in.
@@ -8,7 +8,7 @@ export default function Page() { | |||
return ( | |||
<> | |||
<h1>Operations List</h1> | |||
<Link href="/dashboard/operations/create"> | |||
<Link href="/dashboard/operations/0/1"> |
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 the 0
is unclear because it looks like a real ID (especially because it shows in the breadcrumb:
)
It would be nice if we could create the operation and ID when someone clicks the Add Operation
button. But I assume that doesn't work because there are mandatory fields for creating an operation that the user has to fill out?
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've discussed the breadcrumbs bugs a bit with Shon and this will be fixed. Though it's out of scope for this ticket.
}: FieldTemplateProps) { | ||
const options = uiSchema?.["ui:options"] || {}; | ||
const jsxTitle = options?.jsxTitle as 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.
any type
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.
Yeah RJSF was picky with the type so I am using any, I don't think nits about types is super helpful in a front end web application tbh. Though happy to change it if you find something that works.
steps, | ||
cancelUrl, | ||
classNames, | ||
submitEveryStep, |
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 having trouble with the submitEveryStep
variable. Does it mean that all steps are mandatory? That a user has or hasn't filled all the steps?
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.
submitEveryStep
means the form submits between pages, if not it uses a button without type="submit"
so it won't trigger RJSF validation.
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.
If it's about validation, I'd suggest changing the variable name to something about validation or adding the explanation above in a comment. (Sidenote, why would we ever not want to validate?)
Back | ||
</Button> | ||
)} | ||
{!isFinalStep && !submitEveryStep && ( |
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.
Since I don't understand what submitEveryStep
is, I'm having trouble following the logic here and below
The status handling has a lot of issues and is out of scope for this ticket. We discussed it and created an issue to fix it: Same with the breadcrumbs, out of scope and will be handled in the future. |
c0f1291
to
b8b0beb
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.
const formSection = parseInt(params?.formSection as string) - 1; | ||
const [formState, setFormState] = useState(formData || {}); | ||
|
||
const formSectionList = Object.keys(schema.properties as 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.
Something along these lines would at least ensure it's an object: { [key: string]: any }
steps, | ||
cancelUrl, | ||
classNames, | ||
submitEveryStep, |
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.
If it's about validation, I'd suggest changing the variable name to something about validation or adding the explanation above in a comment. (Sidenote, why would we ever not want to validate?)
@@ -90,10 +90,10 @@ def test_post_new_operation(self, client): | |||
) | |||
post_response = client.post(self.endpoint, content_type=content_type_json, data=mock_operation.json()) | |||
assert post_response.status_code == 200 | |||
assert post_response.json() == {"name": "Springfield Nuclear Power Plant"} | |||
assert post_response.json() == {"name": "Springfield Nuclear Power Plant", "id": 2} |
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 don't think it's safe to assume the correct value is what the test returns. If you just run that single test do you get id=1?
Added a suggestion for how the test case can be revised so that we don't run into issues with a hard-coded id value that might sometimes change. And also found a leftover typo that snuck in in a previous PR. That's all the feedback I have - otherwise I'm happy to get this PR merged in! I think the other nits Brianna mentioned will be addressed in other tickets we have in our backlog. The Operations form is looking super slick @marcellmueller - fantastic work! |
82195d9
to
022e5ba
Compare
022e5ba
to
123048c
Compare
Implements #243
Might be good to take an extra close look at the api changes and updates to the endpoint tests since I am new to Django.
The
PUT: /operations/{operationId}
route now takes a query param?submit=true
so we can set the status topending
on the submission page.This also includes some style improvements to the header, review buttons as well as fixes to the
user operator
form brought over from my abandoned user operator pagination PR.