-
Notifications
You must be signed in to change notification settings - Fork 84
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
LF-4691: UI to connect to ensemble #3675
Conversation
* remove sensor upload related code
* send showPreviousButton prop to ContextForm
607cb74
to
c53bdf2
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.
Looking good!
Left a couple of inline questions ..nothing too important I don't think.
I am not sure if Loading should be under /ContextForm
-- it seems like it should be for all of app or replace existing Loading animation if we are redesigning a new one.
Could consider creating a /Addon
directory and placing Partners cards under it since may be shared between farm settings, add sensors and probably other addons like layers and pivots.
return uuidValidate(value) || errorMessage; | ||
}; | ||
|
||
const PARTNERS = [{ name: 'Ensemble scientific', url: 'www.esci.io', logoPath: EsciLogo }]; |
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.
Should this go in new constants file with the partner id in this object? in addon_partner
table "scientific" is capitalized : 'Ensemble Scientific'
@@ -277,4 +288,6 @@ export const { | |||
useAddSoilAmendmentProductMutation, | |||
useUpdateSoilAmendmentProductMutation, | |||
useGetSensorsQuery, | |||
useLazyGetSensorsQuery, |
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.
Cool ! Is this to start requesting data faster than loading of next component?
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.
Exactly! I'm not sure if I keep it with the updated design though...
|
||
// Proceed to sensors view | ||
onSuccess(); |
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.
Should the form data be cleared here?
Currently when I press save, successfully reach next page, then press back button >>> entered data is still present in input. I think in the future when GET endpoint is ready it will check for existing addon -- so maybe that will handle the need to clear form or not.
styles.loadingScreen, | ||
isCompactSideMenu ? styles.withCompactSideMenu : styles.withExpandedSideMenu, | ||
)} | ||
style={style} |
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.
Is inline styles temporary?
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.
No, it's permanent. This is the only way I know to use dynamic px
values via props in CSS, but if you know a better way, please let me know!
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.
Okay, I didn't see the props being used by any parents yet so thought maybe it was just for testing. Would a className not be able to override variables too?
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.
Ah I see! It should be possible, but we'd have to do isCompactSideMenu ? styles.withCompactSideMenu : styles.withExpandedSideMenu
in the parent component and write this much of CSS for a className, so using style
seems more intuitive and simpler.
.className {
height: calc(100vh - var(--global-navbar-height) - var(--vertical-margin) * 2);
&.withCompactSideMenu {
width: calc(100vw - var(--global-compact-side-menu-width) - var(--horizontal-margin) * 2);
}
&.withExpandedSideMenu {
width: calc(100vw - var(--global-side-menu-width) - var(--horizontal-margin) * 2);
}
@include xs-breakpoint {
&.withCompactSideMenu,
&.withExpandedSideMenu {
width: calc(100vw - var(--mobile-margin) * 2);
height: calc(100vh - var(--global-navbar-height) - var(--mobile-margin) * 2);
margin: var(--mobile-margin);
}
}
}
FormContent: () => <div>Partner selection view</div>, | ||
onContinueAction: linkOrganizationId, | ||
FormContent: () => <Partners />, | ||
onContinueAction: linkEsci, | ||
}, | ||
{ FormContent: () => <div>ESCI devices view</div> }, |
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.
Is this temporary? I don't think ESCI devices view should be a step in the form. I see it looks that way in figma... but I am not sure its appropriate. If we are making a pattern similar to AnimalsSummary we should maybe reuse that instead and redirect to this page.
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 believe it should've been implemented this way with the old header and the back button, and I was going to create another container for the sensor list page. It makes sense to redirect the user to the sensor list page with the updated design!
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.
Thank you @Duncan-Brain !
I'll try to fix the scrollbar. As for the file structure, I'll reorganize it later in a separate PR!
I'll re-open the PR once I apply the updated design. Thank you 🙏
FormContent: () => <div>Partner selection view</div>, | ||
onContinueAction: linkOrganizationId, | ||
FormContent: () => <Partners />, | ||
onContinueAction: linkEsci, | ||
}, | ||
{ FormContent: () => <div>ESCI devices view</div> }, |
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 believe it should've been implemented this way with the old header and the back button, and I was going to create another container for the sensor list page. It makes sense to redirect the user to the sensor list page with the updated design!
styles.loadingScreen, | ||
isCompactSideMenu ? styles.withCompactSideMenu : styles.withExpandedSideMenu, | ||
)} | ||
style={style} |
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.
No, it's permanent. This is the only way I know to use dynamic px
values via props in CSS, but if you know a better way, please let me know!
@@ -277,4 +288,6 @@ export const { | |||
useAddSoilAmendmentProductMutation, | |||
useUpdateSoilAmendmentProductMutation, | |||
useGetSensorsQuery, | |||
useLazyGetSensorsQuery, |
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.
Exactly! I'm not sure if I keep it with the updated design though...
* accept showLoading instead of onContinueAction in steps * accept onAfterSave prop * avoid page transition blocking after form is saved * adjust stories
Updates:
Thank you for re-reviewing! 🙏 |
@@ -92,3 +92,6 @@ export const createCompleteTaskUrl = (id: string | number, hasAnimals: boolean): | |||
// Maps | |||
export const MAP_URL = '/map'; | |||
export const POST_SENSOR_URL = '/create_location/sensor'; | |||
|
|||
// Sensors | |||
export const SENSORS = '/sensors'; |
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.
/sensors?partner_id=1
/addon/1/sensors
I initially presented the first option to the team, but if we prioritize the addon over sensors as Duncan mentioned, we could probably go with something like the second one? Any thoughts?
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.
Both would be good! The first one also adds flexibility if we ever decide we want to have a screen showing all sensors for all manufacturers, which would be /sensors
, but Loïc said we wouldn't want to do that so maybe irrelevant.
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 this is tough, I agree both are good. You could choose either. I just want to keep /map
out of it I think. It might make sense to eventually reach these multiple ways so I think you can choose!
So many thoughts -- but are they useful? haha
Just trying to think about how a farmer might set up an addon. Especially if that addon does multiple things like ESCI -- they provide us with both irrigation prescriptions and sensors. So I can see how navigating from /farm_setting
to /addon
makes sense. (option 2)
But I also understand that eventually (in the distant future) might be need for a /farm_equipment/
module where we would move access to /sensors
or /irrigation_equipment
and then configuring or viewing there. (option 1)
Same with /Insights/irrigation_prescriptions
etc.
Since for some reason we are adding an esci addon (with both prescriptions and sensors) with the "add sensors" button it might make sense either way 🤷
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.
Sorry it took a while for me to review this! This looks soooo good, the loading screen with the animation is on point 🔥 it's so clean! Loving it ❤️
@@ -92,3 +92,6 @@ export const createCompleteTaskUrl = (id: string | number, hasAnimals: boolean): | |||
// Maps | |||
export const MAP_URL = '/map'; | |||
export const POST_SENSOR_URL = '/create_location/sensor'; | |||
|
|||
// Sensors | |||
export const SENSORS = '/sensors'; |
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.
Both would be good! The first one also adds flexibility if we ever decide we want to have a screen showing all sensors for all manufacturers, which would be /sensors
, but Loïc said we wouldn't want to do that so maybe irrelevant.
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.
Looking great I love how ContextForm is improving over time!
Description
Implement the first screen of the add sensor flow.
Partners
component (to be renamed toAddons
or something similar later)PostSensor
containerLoading
component fixed relative to viewport (The file is currently nested within ContextForm, but I plan to extract it in a future PR. Keeping it for now to avoid a bigger diff)Previous
button inWithStepperProgressBar
isCompactSideMenu
prop toPOST_SENSOR_URL
routeMap
componentContextForm
to acceptformMode
prop ("onBlur", "onChange" etc.)Delete unused files and code for bulk sensor uploadJira link: https://lite-farm.atlassian.net/browse/LF-4691
Type of change
How Has This Been Tested?
Checklist: