LF-4788b Create GET endpoint to fetch individual IP from Ensemble (Frontend)

[kathyavini]

Description

This PR is opened according to the original ticket & Ensemble API endpoint specifications. I have decided to create a separate ticket to incorporate the endpoint adjusts needed for the real incoming data, leaving this PR for the mocking solution as originally intended. Note that means this particular branch cannot be used with shouldSend = true -- it will error since much of what Ensemble returns is not what we expected.

Changes Included in this PR:

Backend:

• minor adjusts to the backend-generated mock: more realistic pivot radius + returning a system name (ESci hasn't implemented this yet, but should)

Frontend:

• setting up the RTK Query endpoint, and moving the Prescription Details type into store/api
• remove all frontend-defined mocks
• fix a mutating sort on the VRI data (RTK Query won't permit this on the query hook returned data)
• rearrange reading of prescription data in a few places to fix crashes while data is loading / undefined, and/or to make sure hooks are not called conditionally
• add in the system name to the IP title, and re-name the title-generating function for use in sensors + IP both

Jira link: https://lite-farm.atlassian.net/browse/LF-4788

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain)

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have ordered translation keys alphabetically (optional: run pnpm i18n to help with this)
• I have added the GNU General Public License to all new files

[SayakaOno]

Looks great! Just left one minor comment for potential cleanup.

I noticed there are mocks for the IP API with the comment "LF-4710" (wrong ticket?). Were you aware of it??

[kathyavini]

@SayakaOno thank you, cleaned up! 🙏

I noticed there are mocks for the IP API with the comment "LF-4710" (wrong ticket?). Were you aware of it??

Are you referring to the TODOs from this PR comment here? I don't think it's the wrong ticket but I didn't fully follow the relationship myself; did you?

[SayakaOno]

Oh, I completely missed Duncan's comment, thank you for the link! Those TODOs were exactly what I was referring to.

And no, I didn’t follow the relationship either. I didn't expect the old sensor implementation to be related to the IP...
Also, I didn't think we should delete AddonPartner = 0 from the DB, but should we? I just wanted the code to be simplified the way you suggested eventually, so I brought it up!

[kathyavini]

Also, I didn't think we should delete AddonPartner = 0 from the DB, but should we?

Hmmm, I don't think we have to. There aren't any farm_addon records where the addon partner is 0, regardless of what's in the addon_partner table, and I don't think there is any way to produce them. 🤔

I guess I see the logic in having that map match the keys in the addon_partner table exactly, but I think it's equally legitimate to skip the default "no partner" value and add to the map as functional partners are actually added, right? Let me see about cleaning that up and removing the TODOs!

[SayakaOno]

Thank you Joyce!
I was actually going to approve this earlier but forgot, I'm approving it now! Please merge if the cleanup will be done in a separate PR (I wasn’t suggesting it should be done in this one!).

[kathyavini]

@SayakaOno I pushed the change simultaneous to your comment I think! 😅

[SayakaOno]

It happened at exactly the same time! 🤣
Let me re-review it, thank you! 🙏

[kathyavini]

@SayakaOno I'm gonna be honest, I don't know why Partial addresses that 😂 But for sure it does work and TS is flagging the possibility of missing key now, so let's use it! ❤️

Edit: Hmmm, reading about it, and very interesting. I guess in almost every case for a lookup dict like this we would want to use the Partial<Record<number, ...

[SayakaOno]

ChatGPT says:

Partial<Record<number, T>> tells TypeScript: “This object might only have some number keys — not all of them.”

I'm still not sure what the best approach is in this kind of situation though... I still have more to learn!
Thank you for the update!

Update: It seems best to remove the explicit type when possible, but that’s not always an option...

const animals: Record<string, () => void> = {
  cat: () => ({}), 
}
animals['dog']()  // no error here

const animals = {
  cat: () => ({}), 
}
animals['dog']() // error

[kathyavini]

Really interesting example, thank you! I don't think I've ever thought about that when reaching for a Record<string, ..., and I think we all use it fairly commonly. Very good to keep in mind 🙏