Clarifying the nightscout validation endpoint

[nielsmaerten]

Clarifying the nightscout validation endpoint

[nielsmaerten]

Final note: Merging #40 will not (yet) auto deploy the refactored webhook to Nightly.
It does now :)
To deploy, cd into ./gluco-check-webhooks and run yarn deploy

[ddamico]

Awesome, thanks Niels! My winter break just started so I will have a look at this over the next couple of days.

[ddamico]

Okay @nielsmaerten just about done working through this but want to confirm, url is always present in the response, but token nightscout and discoveredMetrics would be optional, am I reading validate correctly? Or would they be present but empty? ah, nevermind any of this, can see for myself now that it's been deployed to nightly.

[nielsmaerten]

Hi @ddamico
I turned this card into an issue, because I think it may require some additional discussion before it's actually useful.

I currently see 2 issues:

• if a metric is missing from readableMetrics it does not necessarily mean that metric is completely unavailable. Nightscout's API is tricky here: When you have no more Carbs On Board... it does not set COB to 0. Instead, the COB is omitted entirely.
  A metric being unreadable now, does not mean will won't be there at some point in the future.

• canReadStatus doesn't seem very useful from the point of the frontend? Basically, it means the /api/v1/status endpoint is returning data. That should indicate there's a working nightscout site behind the url entered BUT... if the user has set API_DEFAULT_ROLES to denied, there's a working Nightscout site... but canReadStatus will still be false.

[nielsmaerten]

I have some ideas about how to solve these, but I'm curious what you think.

• readableMetrics: I would not block a metric from being selected just because the API can't find it.
• canReadStatus: Maybe I should change this to isNightscoutUrl? I'd run some different logic to detect there's actually a nightscout site there. Then if it's false, it's clear that the user must be instructed to update their url

[ddamico]

Ah these are great points Niels! I see what you mean with readableMetrics, I will not block anything on this. And on canReadStatus, your alternate proposal sounds like a great alternative if the current logic has that level of uncertainty!

Also was thinking earlier today that rather than changing user input based on this response, it makes more sense to provide clear messaging with adjacent helper text. Apart from the "these characteristics of the response could mean a few different things" concerns, it seems to me like a confusing user experience to present the form with "corrections" that wouldn't actually be persisted anywhere unless the user clicks save.

[nielsmaerten]

Hey @ddamico

First off: happy holidays! :)

I found some time to take another look at the validation endpoint, and I've created a PR with a refactored version.
NightscoutValidationResult.ts is the file you'll probably want to take a look at, because that's what the API will be responding with.

If this looks good to you, go ahead and merge PR #40.

---

Also was thinking earlier today that rather than changing user input based on this response, it makes more sense to provide clear messaging with adjacent helper text

Agreed. Something like: when a Metric is missing, we only show some helper text/info bubble to indicate the Metric could not be found? This might nudge the user to not select it after all (eg if they realize they don't enter this info into Nightscout anyways).

it seems to me like a confusing user experience to present the form with "corrections" that wouldn't actually be persisted anywhere unless the user clicks save.

Sounds good! The only real correction here is that the token and url saved to the userDocument should be the 'parsed' versions from the api response.

And on canReadStatus, your alternate proposal sounds like a great alternative if the current logic has that level of uncertainty!

canReadStatus is gone, and replaced with pointsToNightscout. If that property is false, the user will have to correct their URL