Using {{< include >}} or knitr::knit_child() but keeping yaml-params of the child.

[OffByOne37]

Description

Hello, im currently trying to create a presentation from multiple slides, but the slides are seperated in chapters.
I have created a master.qmd file that looks something like this:

master.qmd
---
title: "title of the lecture"
format:
    revealjs
---

'''{r}
#| include: false
library(knitr)
'''

'''{r ,results='asis'}
parameters <- knitr::knit_params(paste(readLines('slide_1.qmd')))

e1 <- new.env()
e1$params$val1<- parameters$val1$value
e1$params$val2 <- parameters$val2value
a <- knitr::knit_child('slide_1.qmd', envir = e1, quiet=T)
cat(a, sep="\n")
'''

The slides will be more complicated, but lets's say they look something like this:

slide_1.qmd

---
params:
    val1: "title"
    val2: true
---

# content of slide_1

The problem is that the params from the slides are not available if i knit them from a parent. Therefore i first need to extract them via knit_params and then I can pass them via the new envir parameter.

Isn't there a better solution?

NOTE: for now I did not implement that I can have multiple chapters, since i first want to resolve the problem with the params. Otherwise i would simply run through all files via a loop and knit them.

[cderv]

This is a limit of how knitr parameters works. YAML definition must be in the main doc YAML header.

However, params definition as YAML is just a wat to defined defaults. Objects are then just transformed to a params R objects.

Why not just have a hidden chunk in your child document that defines this new params object

In slide1.qmd

```{r}
#| include: false
params <- list(
    val1 = "title", 
    val2 =  TRUE)
```

# content of slide_1

This is quite similar in a way of what you are doing, and currently this is how that would work if you want to work with parameters.

Related discussion about child and parameters setting:

• Child documents should accept params yihui/knitr#1884

[OffByOne37]

Thanks for your quick answer.

I know this solution, but didn't like it since it seems quiet static. I mean the title won't be the problem, but the second value is if I want to add Notes or not, I would prefer to keep this dynamic. But I think the cleanest way is to pass a parameter to the child and set "val2" accordingly. Will give it a try!

[cderv]

Then your solution of passing values specificically for the child execution is a good one for dynamic setting.

Currently I see no other. When / If we'll rethink the parameters logic for Quarto to make something more common to Knitr and Jupyter engine, then there will may be other solutions.