-
Notifications
You must be signed in to change notification settings - Fork 24
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
1544/ami overrides + unit form refactor #1706
Conversation
✔️ Deploy Preview for dev-partners-bloom ready! 🔨 Explore the source changes: b5b010e 🔍 Inspect the deploy log: https://app.netlify.com/sites/dev-partners-bloom/deploys/614222308dae9600070adac3 😎 Browse the preview: https://deploy-preview-1706--dev-partners-bloom.netlify.app |
❌ Deploy Preview for dev-storybook-bloom failed. 🔨 Explore the source changes: b5b010e 🔍 Inspect the deploy log: https://app.netlify.com/sites/dev-storybook-bloom/deploys/6142223029c0e90007a733cf |
✔️ Deploy Preview for dev-bloom ready! 🔨 Explore the source changes: b5b010e 🔍 Inspect the deploy log: https://app.netlify.com/sites/dev-bloom/deploys/61422230a9533b00075e81c0 😎 Browse the preview: https://deploy-preview-1706--dev-bloom.netlify.app |
#1575 , which has the backend ami override work, was merged. |
add0a1f
to
55d956f
Compare
✔️ Deploy Preview for clever-edison-cd22c1 ready! 🔨 Explore the source changes: e0a65b8 🔍 Inspect the deploy log: https://app.netlify.com/sites/clever-edison-cd22c1/deploys/61394c7720f950000795f83c 😎 Browse the preview: https://deploy-preview-1706--clever-edison-cd22c1.netlify.app |
af0b1a4
to
db193e5
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.
@emilyjablonski ,
This is definitely looking better than where it was and it's much easier to follow the event loop . I have a couple of question/consideration comments on the code.
Other than that, I have a general question of how should we handle a user entering in a percentage that is not in the chart? Let's say that a user selects a chart and then adds 50, which has a match in the chart, but then changes it to 45, which doesn't. On the form now, the fields don't clear out, but if I edit an entry, save it and reopen, I will only see the value I added. I think we should either clear out the fields if they add a percentage that isn't in the chart, or we update the percentage field to be a select based off of the available, unique percentages in the chart.
const thisAmiChart = await amiChartsService.retrieve({ | ||
amiChartId: defaultChartID ?? amiChartID, | ||
}) | ||
const amiChartData = thisAmiChart.items | ||
.filter((item) => item.percentOfAmi === parseInt(defaultAmiPercentage ?? amiPercentage)) | ||
.sort(function (a, b) { | ||
return a.householdSize - b.householdSize | ||
}) | ||
setCurrentAmiChart(amiChartData) | ||
amiChartData.forEach((amiValue, index) => { | ||
setValue(`maxIncomeHouseholdSize${index + 1}`, amiValue.income.toString()) | ||
}) |
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.
Would it make sense to decouple the fetching of the ami chart from setting the ami chart values? I know we want to fetch the chart on chart change, do we need to do that on ami percentage change too? Since this shouldn't be something that's getting changed too much, I'd rather stay on the side of simplicity, so if pulling those two pieces apart complicates the flow, then let's keep as is.
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.
Makes sense, I changed amiPercentage to be a select based on the available percentages in the selected chart and am only fetching new charts on chart change
const existingId = units.filter((unit) => unit.tempId === defaultUnit?.tempId)[0]?.tempId | ||
const nextId = units.length + 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.
Would it simplify things to pass defaultUnit.tempId as the id we expect it to be already? And if that's the case, then could we also pass in a new prop for nextId to use in the case where the user is doing a & new
action?
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.
Passing two new props for the IDs and removed units as a prop
<table> | ||
<thead> | ||
<tr> | ||
<th>{t("listings.householdSize")}</th> | ||
<th>{t("listings.maxAnnualIncome")}</th> | ||
</tr> | ||
</thead> | ||
<tbody>{getAmiChartTableData()}</tbody> | ||
</table> |
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 you set the same classes on these fields here as what MinimalTable/StandardTable set, I think we can probably get it pretty close to what they gives us.
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.
Added styles to make it match
.filter((item: AmiChartItem) => item.householdSize === index + 1) | ||
.filter((item: AmiChartItem) => item.percentOfAmi === parseInt(amiPercentage))[0] |
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 didn't notice this before, but can you make this a single filter?
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.
@emilyjablonski ,
This looks good and seems to be working well. There's some minor cleanup and then I think you can merge.
@@ -33,6 +33,7 @@ import { | |||
PaperApplication, | |||
PaperApplicationCreate, | |||
ListingReviewOrder, | |||
UnitAmiChartOverrideCreate, |
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 this is used now.
void resetDefaultValues() | ||
}, []) | ||
|
||
const fetchAmiChart = async (defaultChartID?: string, defaultAmiPercentage?: string) => { |
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.
defaultAmiPercentage isn't used
setValue("priorityType.id", defaultUnit.priorityType?.id) | ||
setValue("unitType.id", defaultUnit.unitType?.id) | ||
} | ||
}, [options]) |
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 linter is complaining about the dependency arrays for this and two others. Does updating them cause issues?
47edb36
to
37fd381
Compare
Pull Request Template
Issue
Addresses #1706
Description
Adds the ability to create ami chart overrides in listings management, and also due to lots of state issues refactors the UnitForm component.
Type of change
How Can This Be Tested/Reviewed?
Create a new listing. Set an ami chart. Set an ami percentage from the dropdown (will pulls unique ami percentages from the selected dropdown). The table should populate with the ami chart values. Change one of the values (creating an override). Save the unit. Re-open the unit before saving the listing and ensure the override is still there. Change the percentage and the chart and ensure the override isn't sticky.
Save a listing with a unit with an overrides and view the details page for that unit and ensure the only value saved as an override is the one(s) that was overridden and that the default values aren't duplicated.
Ensure Copy and New works and brings overrides with it. Ensure Save and New and Save and Exit work as well.
Open an existing seeded listing to edit it and ensure the ami values populate.
Checklist: