-
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
fix: data from deleted depth intervals should not be sent to the soil id algorithm #2912
base: main
Are you sure you want to change the base?
Conversation
6a29b93
to
fff92c8
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.
Please have Garo review/approve.
Co-authored-by: Paul Schreiber <[email protected]>
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, the only areas for improvement i can see would be code organization/refactoring in selectors.ts
but what else is new!
@@ -0,0 +1,257 @@ | |||
/* |
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.
noice \o/
const getSoilDataForSite = ( | ||
siteId: string, | ||
soilData: Record<string, SoilData | undefined>, | ||
) => soilData[siteId] ?? DEFAULT_SOIL_DATA; | ||
|
||
export const selectSoilData = (siteId: string) => (state: AppState) => | ||
getSoilDataForSite(siteId, state.soilData.soilData); | ||
|
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.
question: is there any situation where we want to use the naive getSoilData
/selectSoilData
? if not, would it make more sense to instead name these getRawSoilData
or something similar, and name the getVisible
ones just get
if they're the default that we always want to be using everywhere? recognizing this is probably a pain in the butt to refactor 🙃
...projectOrPresetIntervals.map(interval => { | ||
const existingInterval = effectiveSoilData.depthIntervals.find( | ||
sameDepth(interval), | ||
); | ||
const enabledInputs = fromEntries( | ||
soilPitMethods.map(method => [ | ||
methodEnabled(method), | ||
effectiveProjectSettings?.[methodRequired(method)] || | ||
(existingInterval?.[methodEnabled(method)] ?? | ||
(!effectiveProjectSettings && | ||
DEFAULT_ENABLED_SOIL_PIT_METHODS.includes(method))), | ||
]), | ||
); | ||
return { | ||
isFromPreset: true, | ||
interval: { | ||
...enabledInputs, | ||
...interval, | ||
}, | ||
}; | ||
}), | ||
...effectiveSoilData.depthIntervals | ||
.filter(interval => !projectOrPresetIntervals.some(overlaps(interval))) | ||
.map(interval => ({ | ||
isFromPreset: false, | ||
interval: { | ||
...interval, | ||
...fromEntries( | ||
soilPitMethods.map(method => [ | ||
methodEnabled(method), | ||
interval?.[methodEnabled(method)] ?? | ||
DEFAULT_ENABLED_SOIL_PIT_METHODS.includes(method), | ||
]), | ||
), | ||
}, | ||
})), |
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.
comment: recognizing that i'm the one who created this monstrosity... wow this is hard to parse!
Description
Product code:
selectNextDataBasedInputs
, which is what creates the input data sent to the soil id algorithm, would send all depthDependentData as input data.getVisibleDepthIntervalsAfterNormalizing
is. Taking suggestions for better names and if there are ways to make this cleaner.Tests:
getVisibleSoilDataForSite
selectNextDataBasedInputs
Related Issues
Fixes #2875
There will also be a backend change for editing depth intervals
Verification steps
In dev environment:
sudo tcpdump -i lo0 port 8000 -A
to see what inputs get sent when we push soil data, and what we use to query for soil id matches