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

fix: data from deleted depth intervals should not be sent to the soil id algorithm #2912

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

knipec
Copy link
Contributor

@knipec knipec commented Feb 19, 2025

Description

Product code:

  • Previously: selectNextDataBasedInputs, which is what creates the input data sent to the soil id algorithm, would send all depthDependentData as input data.
  • Now: "Next inputs" to the algorithm will only include the depthDependentData for depth intervals that are visible to the user. The logic to determine "visible" depth intervals was basically being done already via hooks, so I tried to extract functions for the reusable logic. That's what getVisibleDepthIntervalsAfterNormalizing is. Taking suggestions for better names and if there are ways to make this cleaner.
  • Minor refactor: Also, in soilIdMatchActions, fetchDataBasedSoilMatches expect coords, so just send that instead of entire set of site properties

Tests:

  • Add tests for new function getVisibleSoilDataForSite
  • Add tests for changed behavior of selectNextDataBasedInputs
  • Refactor: Moved functions from selectors tests into a utils file to use them in another test

Related Issues

Fixes #2875
There will also be a backend change for editing depth intervals

Verification steps

In dev environment:

  • I'm using 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
  • Confirm that we newly query for soil id matches when a depth interval is deleted or edited
  • Confirm that only visible depth intervals are sent as input when we query for soil id matches

Copy link
Member

@paulschreiber paulschreiber left a 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]>
Copy link
Member

@shrouxm shrouxm left a 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 @@
/*
Copy link
Member

Choose a reason for hiding this comment

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

noice \o/

Comment on lines +335 to 342
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);

Copy link
Member

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 🙃

Comment on lines +373 to +408
...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),
]),
),
},
})),
Copy link
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deleted depth intervals are still sent to the soil-id-algorithm
3 participants