What is Unit displays?
Please see the introduction in https://lite-farm.atlassian.net/l/cp/rCoihsHd.
The frontend has a component named “Unit” which handles unit displays(/packages/webapp/src/components/Form/Unit/index.jsx).
How does the Unit component look on the app?
simple usage
system generated(pre-populated)
system generated(pre-populated)
disabled
“hide label”
automatic conversion
Guidance for Default unit displays with examples
How does farm’s unit setting(metric/imperial) affect this on read/edit view? If record-to-record unit(user preference) is “cm” but the user’s unit setting is imperial, should we follow the default display guidance? (
LF-2880
-
Getting issue details...
STATUS
)
is there a guidance for depth and spacing?
When the value is(was) pre-populated by the system | When a value is NOT pre-populated by the system or was user created | |
|---|---|---|
create | the https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/658309153/Unit+displays#Default-display-guidance should determine the value / unit combination ex.  | the user set unit preference should be used
 |
read-only | the https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/658309153/Unit+displays#Default-display-guidance should be used ex.  | the user set unit preference should be used  |
editing | the https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/658309153/Unit+displays#Default-display-guidance should be used ex. 
| the user set unit preference should be used  |
automatic conversion - we will go with easier solution.
We do not need to see automatic conversion at all? (how about total area?)
Scenarios
User’s unit system setting is “imperial”. The user created a barn and total area was 50,000 acres. After that, he switched the unit system to “metric”.
-> The total area should be displayed in ha.User’s unit system setting is “imperial”. The user created a crop plan with planting depth 3 inches.
-> The depth should be stored in XXX.
“depth” is not in the https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/658309153/Unit+displays#Default-display-guidance
(This is not 100 percent accurate)
| Path | Number of unique <Unit /> (59) & Views | Type | Operation | automatic conversion | Note |
|---|---|---|---|---|---|---|
1 |
file: | 4 
| user input | create | NO | Currently, raw data(what the user has inputted is stored in the DB. After switching unit system, data conversion does not happen. |
2 |
file: | 3  | - | read | - |
|
3 |
file: | 3  |
| create | NO |
|
4 |
file: | 1  | user input | edit | NO |
|
5 |
file:
| 1  | - | read | - |
|
6 |
file: | 2   | user input | create | NO |
|
7 |
file: | 5 (4) 
These should be combined ⬇️  | user input | create | NO |
|
8 |
condition:
file: | 1  | user input | create | NO |
|
9 |
condition:
file: | 1  | user input | create | NO |
|
10 |
condition: 
file: | 1  | user input | create | NO |
|
11 |
the component is used for #2
file: | 5   | user input | create | NO | Estimated seed 20lb was saved in the DB |
12 |
file: | 2  | user input | create/edit? | NO |
|
13 |
file: | 2 | user input | create edit | - |
<Unit /> does not need to be used for $… |
14 |
file: | 2  | pre-populated | create | NO |
|
15 |
file: | 2  | pre-populated | create read edit | NO |
|
16 |
file: | 1  | pre-populated | create | NO |
|
17 |
file: | 4  | pre-populated / user input | create read edit | NO |
|
18 |
file: | 1  | - | read | - |
After adding sensors with “150cm” and “200cm”, they were shown as “1.5m” and “2cm”. |
19 |
file: | 1  | user input | create | NO |
|
20 |
file: | 2  | pre-populated | create | - |
|
21 |
file: | 6   | user input | create | YES |
|
22 |
file: | 1  | pre-populated (reading the data in DB) | edit | NO |
|
22 |
file: | 1  | user input | create | NO |
|
23 |
file: | 1  | user input | create | NO |
|
24 |
file: | 1 
| user input ↔︎ disabled by checking “harvest everything” | create | NO |
|
25
|
file: | 2  | - | read | - |
|
26 |
file: | 1 | user input | create | YES | When I input “2 gal” in the estimated water usage input, “2 gal” was saved in the DB. |
27 |
file: | 1  | user input | create | NO |
|
28 |
file: | 1  | user input | create | NO |
|
How is the conversion happening?
WIP
What is the problem and why are we working on this?
There have been some bugs found on Unit displays. However, there were times that a bug fix affected another Unit component that was functioning before. The unit component is used in many different places and requirements for each unit are vary. For instance, in some views, value and unit is generated based on the guidance, and in other views, they are inputted by the user. Sometimes the values need to be converted to another unit and sometimes they are not. It is thought that the component has a good amount of code of logic to handle all of these cases, which makes it hard to be maintained and scaled. As of February 10, 2023, the component is used in 59 different instances across 29 different files in the webapp. According to Jag Dhillon, in order to fix existing bugs and not to introduce new bugs, refactor is required.
How are we going to address this issue?
Jag Dhillon says “The unit component has multiple different useEffects that are causing most of this tight interdependency”, “the problem is the code is tightly coupled and minor changes to the code easily break some of the 56 component instances throughout the app.” in his proposal.
Approaches and estimates
- Any proposed architectural refactor must be implementable by 1 engineer in 3 sprints (6 weeks) or less
- Architecture supports the ability for the user to define how unit switching works for them (see https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/658309153/Unit+displays#A-note-on-changing-units-when-a-value-has-already-been-entered)
Jag Dhillon’s proposal is to decouple the logic from the unit component, and he suggested we move the logic to the backend. The other approach is to fix and enhance the unit component. By looking into the code, it seems to me that bug fixes have been done without understanding how the unit component was intended to work. As of February 22, 2023, I have had the chance to look at how the value is converted on the frontend, and I liked the approach. I have not looked at how the data is converted from “save as” unit in the DB to “display” unit(I could not find anything working…), but I would like to move in the direction of fixing and improving what we have now. The main reason is to avoid changing many files and the time required for testing. (I will make sure it will be bug free and easy to maintain as well)
Here is the comparison between the two approaches:
proposed approach | alternative approach | |
|---|---|---|
backfill data | find wrong data and write a script | |
database | no change required | |
APIs |
| no change required |
frontend |
|
|
auto conversion | DB: need migration | |
backend: update the helper(?) to take user setting into account | frontend: update the hook(?) to take user setting into account | |
pros |
|
|
cons |
|
|
TODO
ask for answers to all questions and make the requirements crystal clear → create a document(how each Unit input works, how the data is stored in the DB, min&max value(?) etc) that can also be used as a reference for testing
save data in an apples-to-apples manner
show data correctly on the frontend
write tests
figure out which data needs to be backfilled and how → write a script. LF-2719 - Getting issue details... STATUS
we need to deploy APIs & app after backfilling is complete. Do we know how?
Questions:
update the style? LF-2910 - Getting issue details... STATUS