"Best" Workaround for Passing NAs to quarto::quarto_render?

I wanted to get some thoughts on why the workaround (i.e., my interpretation of implementing #264 during runtime) below might be a bad idea, and if there is a more agreed upon recommendation for addressing my issue. Specifically, how to navigate situations where there are NAs in your execute_params when calling quarto::quarto_render. I realize this is a bit of a moot point and there are some high-level constraints (see #168 ); however, this likelihood of this situation in the wild compelled me to bring it up (...again, my apologies for that).

Workarounds for NA in Execute Params

I do appreciate the helpful error message (see #264 ). As a bit of a novice with quarto and its dependencies, I found the recommended alternatives/workarounds a little unclear in terms of how to best implement them. I don't feel that elaborating on this falls on the authors/maintainers of quarto—the current error message is super helpful as-is—which is another motivator for starting this discussion.

The first suggestion:

• Remove NA values from your data before passing to Quarto

This gets at more of a philosophical issue, and the difference in values that are missing versus values that don't exist. Within the context of a quarto document, NA values might still be meaningful/informative. If, for example, one is creating reports for students or test-takers and they are missing scores that they should have. But I'll concede that this works in a lot of situations, though unfortunately not in my situation.

The suggested workaround:

• Handle missing values within your document code using conditional logic

This one is a little murky to me because it seems like it relates to a situation where you have NAs as pre-existing defaults in your params, or you are knitting from within the qmd file. The "handle" part made me think of using a custom handler to deal with NAs when r params are converted to YAML, but I given the internal method quarto:::as_yaml() and existing handlers quarto:::yaml_handlers, I didn't know if this was appropriate.

The other suggestion:

• Use NULL instead of NA for missing optional parameters

Seemed a bit more tenable, but also more brittle--which is why I am soliciting feedback. Here, is how I interpreted it:

Example Passing list(NULL) instead of NA to quarto_render

My File looks like this:

na-test.qmd

---
title: "Quarto NA Param Test"
format: html
engine: knitr
params:
  x: [0]
  y: [""]
---

## Testing How NA is Passed to R > YAML > Quarto

 ```{r}
unlist(params$x)
```

```{r}
unlist(params$y)
```

Running Test

# define params
## list(NULL) replacing NA
x <- c(1:5, list(NULL))
y <- c(list(NULL), letters)

# run render
quarto::quarto_render("na-test.qmd", execute_params = list(x = x, y = y))

Output

na-test.html

Testing How NA is Passed to R > YAML > Quarto

unlist(params$x)

[1]  1  2  3  4  5 NA

unlist(params$y)

 [1] NA  "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r"
[20] "s" "t" "u" "v" "w" "x" "y" "z"

Limitations

• Substituting NAs with list(NULL) makes atomic vectors recursive (so unlist() may need to be called)
• yaml::as.yaml(c(letters, NA)) is not identical to yaml::as.yaml(c(letters, list(NULL)), in the former NA in converted to .na.character in the latter it's converted to ~

Anything else?

Review issues #264 and #168 alongside quarto::quarto_render handling of execute_params. Inspect the mentioned quarto:::as_yaml and quarto:::yaml_handlers internals, then reproduce the na-test.qmd example; done means reaching and documenting an agreed recommendation for representing missing values.