-
Notifications
You must be signed in to change notification settings - Fork 3
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
MCR-3900 Can continue or save as draft with new API #2313
Conversation
I think I'm seeing an issue with the API. It seems to be creating Getting this error back
|
RateRevision: { | ||
fields: { | ||
formData: { | ||
merge: 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.
Getting GQL warnings (not blocking but they clutter the console) because form datas dont have id
but are nested objects that are changing.
Following docs, I believe this is the proper way to address but welcome other eyes.
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.
interesting, funny because these aren't really stand alone objects, we just made formData to wrap the data up nicely. This looks right to me based on those docs
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.
Looks good. I am a little surprised at the dual headed nature of this component but that's for another time
attribute: boolean | Date | string | null | undefined | ||
): string => { | ||
function formatForForm<T> ( | ||
attribute: T |
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 suspect you could just use any
here and it would work the same as the generic parameter
@@ -16,7 +16,7 @@ describe('LinkYourRates', () => { | |||
onSubmit={(values) => console.info('submitted', values)} | |||
> | |||
<form> | |||
<LinkYourRates fieldNamePrefix="rates.1" index={1} /> | |||
<LinkYourRates fieldNamePrefix="rateForms.1" index={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.
good name change
// Set up data for form. Either based on contract API (for multi rate) or rates API (for edit and submit of standalone rate) | ||
const ratesFromContract = | ||
fetchContractData?.fetchContract.contract.draftRates // TODO WHEN WE IMPLEMENT UPDATE API, THIS SHOULD ALSO LOAD FROM ANY LINKED RATES | ||
const initialRequestLoading = fetchContractLoading || fetchRateLoading |
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.
Ok, now I think I see where you are skipping requests. I'm a little surprised by this pattern, seems like a lot of overhead is required in order to use this component for both stand alone rate edit and inside of the RateDetails array. No need to change this now but I'd like to look at that after summit again.
} | ||
|
||
// convert from FormikRateForm to GQL RateFormData used in API | ||
const convertRateFormToGQLRateFormData = ( |
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 like having these explicit converters
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.
Same, this is a great addition!
Yes hoping we remove this and that we get to actually do this right. I still would like to see a SINGLE and MULTIPLE RateDetails v2 also with separation of concerns. However, I was finding keeping that interface clean and also figuring out how to encapsulate the API requests and their handling challenging. A bit hard to refactor and do forward facing work with the short timeline. Putting them together helped me see more clearly what's the same (for standalone v multiple rates) and whats different in one file. Made me more confident I didnt totally break single rate experience |
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
Summary
Happy path for Continue and Save As Draft - using the new
updateDraftContractRates
mutation on ContinuerateForms
instead ofrates
. I'm sorry for the code diff. It was getting very confusing to me in the code when we hadrates
as in GQL rates and when we had rate forms coming from Formik. Tried to make naming more distinct.LinkYourRates
a level up so that I can control form data using theFieldArray.replace
in next PRnavigate
callRelated issues
https://jiraent.cms.gov/browse/MCR-3900
Screenshots
Test cases covered
generateUpdatedRates
utilityQA guidance
Note: Linked Rates radio and dropdown won't hook in yet - thats the next set of PRs