Consider {shinyvalidate} for user input-related warnings/messages

[matt-dray]

{shinyFeedback} may relieve us of some {shinyjs} hide()/show() code smells in the selection app.

[StatsRhian]

Agree that proper validation should be used instead of show() / hide()
Suggest perhaps going with {shinyvalidate} over {shinyFeedback} as it's supported by RStudio and has been updated slightly more recently.

[matt-dray]

It was the little icons that grabbed me with {shinyFeedback}. We should probably prefer stability/support though.

[StatsRhian]

Agree that shinyFeedback is cuter 😍

[matt-dray]

A downside: {shinyvalidate} doesn't suport HTML or Markdown, so we can't add links into the messages. We have a mailto link in the warning shown when the user selects 2023/24 as the baseline year (but we could just show the email address for people to copy), and also when we link to the model updates page re the upgrades and when the user's selected scenario is prior to 2023/24 and can't be upgraded (it would be nice to include these links directly).

Edit: but wait.

  iv <- shinyvalidate::InputValidator$new()

  iv$add_rule(
    "start_year",
    function(start_year) {
      if (start_year == 202324) {
        htmltools::div(
          "You must request and review your 2023/24 detailed baseline data ",
          "before selecting 2023/24 as the baseline year. Contact ",
          htmltools::a(
            "mlcsu.su.datascience@nhs.net",
            href = "mailto:mlcsu.su.datascience@nhs.net"
          ),
          "to do so."
        )
      } else {
        NULL
      }
    }
  )

  iv$enable()

[matt-dray]

And now I'm back to thinking this is more complicated than originally thought. The example above has a straightforward condition. But others are more complex. For example, the warning about upgrading population projection variants to the new ONS 2022 default (i.e. migration category) depends on three conditions: scenario_type == "Edit existing", !is_dev_or_new and extract_major_version(version_string) < 4. The latter two are dependent on knowing the attributes of the params object p. But their identity will change when the user makes selections and p is updated. So we need is_dev_or_new and extract_major_version to be reactives, probably? Then they can be used in the validation rules so that the rules will react to changing user inputs.