Feat: Alerts per check

[VikaCep]

Closes https://github.com/grafana/synthetic-monitoring/issues/186

UI implementation for the new alerts per check.

Some considerations:

• The new alerts are under a feature flag. Set sm-alerts-per-check to true to see them.
• In this PR Chore: introduce Fishery as object factory and yarn dev:msw #1023 I've introduced a new mocked API response which adds the ability to start the app using yarn dev:msw, and allows us to mock the requests both in the app and tests.

Screenshots:

• POST request

• GET request

[ka3de]

Thanks for making time to work on this @VikaCep ! 🙌
I will not make comments on the code because that's beyond my knowledge, but I have a couple of small comments on the UX, I would not consider these as blockers for this PR, but something that we can consider including in the long run.

The first one is that thresholds show no units. I think it could be helpful to specify the units for each threshold, for example whether the threshold refers to a %, or if it is supposed to be defined in seconds (s), milliseconds (ms) or days, etc.

The second one we have already discussed it briefly, personally I think the alerts that support multiple percentiles look better grouped in a single "panel" as the previous iteration? In that case, though, we would need to figure a way to allow users to set different threshold values for the different percentiles, in case that more than one is set, as the same value would probably not make sense for all of them. If we finally opt for this solution and there is something that we have to change in the way the API behaves, let me know and we can work it out also.

[ckbedwell]

I need to do a much more thorough review of the UI/UX but I'd like to explore how we can do that by mocking the data in someway first.

I've focussed mainly on things I can see in the code first that will be agnostic to any of the other changes we'll discuss 😃

[ckbedwell]

I'll do a much more thorough review of the UI/UX separately but just a heads up I don't think we should use cards but probably a table of some sort.

[majavojnoska]

I agree with @ka3de that setting units will clarify what is being measured.

When it comes to the UI, my initial impression was that the cards functioned as radio buttons, allowing only one selection, due to the icon in the top right corner. However, after reviewing Daniel's Slack video, I understand users can set multiple alerts.

A more elegant solution would be to replace the icons with a clear on/off indicator on the left side of each card. This would improve clarity. Also, I would suggest a more condensed card layout to reduce the prominence of the description. Let's discuss this further at our next meeting.

[VikaCep]

Setting the PR to draft until we settle on the UI/UX changes and address them.

[VikaCep]

Thanks @ka3de! Added the default values:

[w1kman]

Works mint now.

Nit: The label thingy is a bit off center though.

[VikaCep]

Update with the header text centered

[VikaCep]

I've removed the mocked data as now the API is available in dev 🚀

[VikaCep]

I have made some updates based on @ckbedwell comment on Slack:

Shared (validate both sides?)

1. I can submit values that should be invalid. I submitted 1000% here for Probe Failed Executions Too High and it got converted to 999.99 which is still too high by about 900 😅

UI/UX

1. If I delete everything in the input field it resets to 0 and I can't delete the 0. If I want to type 10 it appears as 010 (if I select all then type I can get rid of the 0)
2. I found just visiting the alerts section changes the form state so even if I make no changes to my check I get the Unsaved changes modal
3. The double alert notification is confusing. I know they are separate APIs but we shouldn't render the alert update even if successful. Which brings us onto:
4. I like that if the alerts api fails we stay on the page but we have to make this experience nicer even if it should be very rare as it is very confusing what just happened. We need to be more explicit that the check did save but its associated alerts did not. Let's handle this problem in a separate PR but we need to address it.

• Added validation on percentage values, not allowing to go higher than 100%:
  

• Fixed the issue that wouldn't allow to delete the 0:
  

• Removed the double alert notification, showing only the "check saved/updated" one:
  https://github.com/user-attachments/assets/7db8709c-d82a-452d-a2b2-0368725b5a80

• Fixed the issue that showed "Unsaved changes" after the alerts loaded, even if there were no alert changes:
  https://github.com/user-attachments/assets/fcbf0dec-271c-4cb2-acc5-b672aa4af043

[w1kman]

When using scientific notation, it's possible to save the form with a 0 as a value.

E.g. Entering 1e-100 can be saved, which results in a 0. If that scenario is triggered, the form step is still validated as an error (if you go to the next step) but without indication on what is the actual error.

If there is a step error (follow instructions above to trigger), it's not possible to empty the field. If the field says 0, the 0 cannot be removed, only overwritten.

When in a broken state, there is no error message on entering an invalid value. The value may also be "randomly" removed when switching step/section.

[VikaCep]

When using scientific notation, it's possible to save the form with a 0 as a value.

I added a validation to prevent users from entering numbers in scientific notation in the threshold inputs. I also added a min value of 0.01 as after discussing with @ka3de, he told me values with more than two decimals are disregarded in the database (so sending 0.001 would be converted to 0.00)

[ckbedwell]

Small one to avoid the unnecessary type assertion. This is pretty much ready to go so will approve after that ⭐

[ckbedwell]

LGTM 🌟

[ckbedwell]

policy bot: approve