Should be "the" GitHub Actions status badge?

Should be https://github.com/NCEAS/vegbank-web/releases

Should be https://github.com/NCEAS/vegbank-web/issues

Should be https://github.com/NCEAS/vegbank-web

Copyright [2025] [Regents of the University of California]

Just for completeness, here's an equivalent way to get the top dates using chained dplyr verbs, similar pattern to what I suggested in other comments. You could make an argument that it's better to stick with base R functionality especially when you can do so with readable code, though we already depend on dplyr, and these are very standard usages of core, stable dplyr functions for tabular data manipulatino. Toss up in my mind.

    date_formats <- c("a, d b Y H:M:S z", "d b Y H:M:S", "Y-m-d H:M:S")
    top_dates <- data |>
        dplyr::select(original = date_field) |>
        dplyr::mutate(parsed = lubridate::parse_date_time(
            data[[date_field]], orders = date_formats)) |>
        dplyr::filter(!is.na(parsed), !duplicated(parsed)) |>
        dplyr::arrange(dplyr::desc(parsed)) |>
        utils::head(n)

I find this more readable than the previous two suggestions, but am warming up to all of them, thanks.

@regetz Thanks for these suggestions, I think ultimately we may want this summarization to occur on the backend where it can access the totality of the data or whatever we've queried. The overviews are currently not functional after I've started using the paginated data in the table, but it's valuable seeing the other ways to phrase the same functionality using dplyr anyway.

Similar comment to elsewhere, you should be able to drop the .data$ accessor throughout the ggplot expressions here. But then I think you'll need to use longitude and latitude, assuming those are the full column names in the data. The $ in R does partial matching, I guess for convenience, but in my experience it's just a source of bugs!

Probably shouldn't drop .data$, again as per above... See https://dplyr.tidyverse.org/articles/in-packages.html#data-masking-and-tidy-selection-notes

I'm not 100% sure the linter won't balk at this, but I'd move this closing parenthesis to the end of the previous line, then indent the parenthesis on the next line by two spaces. That way the entire ggplot expression is easier to see because all of the continuation lines are intended relative to the initiating ggplot2::ggplot(...) call.

Linter doesn't like it

Kinda surprised me to see this file in the root directory, but I do see precedent for it (like here). Seems like another option is maybe in inst/? Just wondering out loud what is best. No need to change anything now. Important thing is that wherever it is, (a) the package validates fine, and (b) we're able to easily deploy and start the Shiny app in both development and production modes.

same. I don't know where it should go, but it seems like the root isn't the best default location. It would be a shiny-specific recommendation is my guess. Mastering Shiny says to put in the R directory. Maybe let's discuss on slack. https://mastering-shiny.org/scaling-packaging.html#converting-an-existing-app

Not totally sure what's happening here, but the embedded mapply seems atypical in this context. Seems like neither than nor the sprintf are needed? I think this simplified code yields the same thing:

      data_grouped <- data %>%
        dplyr::group_by(.data$latitude, .data$longitude) |>
        dplyr::mutate(
          authorobscode_label =
            paste0(
                "<a href=\"#\" onclick=\"Shiny.setInputValue('label_link_click',
                '", obsaccessioncode, "', {priority:'event'})\">", authorobscode,
                "</a>", collapse = "<br>")
        ) |>
        dplyr::ungroup()

And a second question/comment: With the combination of group_by and mutate, the code here is producing one output record per input record. So for records with the same lat and lon, it's producing a "grouped" HTML snippet (per the collapse = "<br>"), but repeatedly for every member of that group. Is that the intent? If the goal is to produce one single HTML snippet for each unique lat x lon grouping, then we should use dplyr::summarize rather than dplyr::mutate.

Yup, this is what I was referring to when I said I realized after cutting the PR that I was making too many labels and misusing the grouping. I've since changed it to summarize, but I appreciate the validation that that was the right move.