mention all figures + correct index

1-01-intro-introduction.Rmd

@@ -122,7 +122,7 @@ Note that there are also two other prominent ways one can use JavaScript with R
 
 ### reactR & vueR {#intro-reactr-vuer}
 
-[ReactR](https://react-r.github.io/reactR/) [@R-reactR] is an R package that emulates very well htmlwidgets but specifically for the [\index{React} framework](https://reactjs.org/). Unlike htmlwidgets, it is not limited to visual outputs and also provides functions to build inputs, e.g., a drop-down menu (like `shiny::selectInput`). The [reactable package](https://glin.github.io/reactable/) [@R-reactable] uses reactR to enable building interactive tables solely from R code as shown in Figure \@ref(fig:reactable-example).
+[ReactR](https://react-r.github.io/reactR/) [@R-reactR] is an R package that emulates very well htmlwidgets but specifically for the [React\index{React} framework](https://reactjs.org/). Unlike htmlwidgets, it is not limited to visual outputs and also provides functions to build inputs, e.g., a drop-down menu (like `shiny::selectInput`). The [reactable package](https://glin.github.io/reactable/) [@R-reactable] uses reactR to enable building interactive tables solely from R code as shown in Figure \@ref(fig:reactable-example).
 
 ```{r, eval=FALSE}
 reactable::reactable(iris[1:5, ], showPagination = TRUE)
@@ -133,7 +133,7 @@ t <- reactable::reactable(iris[1:5, ], showPagination = TRUE)
 include_widget(t, "01-reactable.png")
 ```
 
-There is also the package vueR [@R-vueR], which brings some of \index{Vue} to R.
+There is also the package vueR [@R-vueR], which brings some of \index{Vue}Vue to R.
 
 ### r2d3 {#intro-r2d3}
 

1-02-basics.Rmd

@@ -225,7 +225,7 @@ Note whilst this short guide will help you develop packages good enough for your
 
 ## JSON {#basics-json}
 
-\index{JSON} (JavaScript Object Notation) is a prevalent data _interchange_ format with which we will work extensively throughout this book; it is thus crucial that we have a good understanding of it before we plunge into the nitty-gritty. As one might foresee, if we want two languages to work together, we must have a data format that can be understood by both---JSON lets us harmoniously pass data from one to the other. While it is natively supported in JavaScript, it can be graciously handled in R with the [jsonlite package](https://CRAN.R-project.org/package=jsonlite) [@R-jsonlite] it is the serialiser used internally by all R packages that we explore in this book.
+JSON\index{JSON} (JavaScript Object Notation) is a prevalent data _interchange_ format with which we will work extensively throughout this book; it is thus crucial that we have a good understanding of it before we plunge into the nitty-gritty. As one might foresee, if we want two languages to work together, we must have a data format that can be understood by both---JSON lets us harmoniously pass data from one to the other. While it is natively supported in JavaScript, it can be graciously handled in R with the [jsonlite package](https://CRAN.R-project.org/package=jsonlite) [@R-jsonlite] it is the serialiser used internally by all R packages that we explore in this book.
 
 ```{block, type='rmdnote'}
 "To serialise" is just jargon for converting data to JSON.
@@ -313,7 +313,7 @@ Jsonlite provides many more options and functions that will let you tune how JSO
 
 The book is not meant to teach JavaScript, only to show how graciously it can work with R. Let us thus go through the very basics to ensure we know enough to get started with the coming chapters.
 
-The easiest way to run JavaScript interactively is probably to create an \index{HTML} file (e.g.: `try.html`), write your code within a `<script>` tag and open the file in your web browser. The console output can be observed in the console of the browser, developer tools (see Figure \@ref(fig:trying-js)).
+The easiest way to run JavaScript interactively is probably to create an HTML\index{HTML} file (e.g.: `try.html`), write your code within a `<script>` tag and open the file in your web browser. The console output can be observed in the console of the browser, developer tools (see Figure \@ref(fig:trying-js)).
 
 ```html
 <!–– index.html ––>
@@ -355,7 +355,7 @@ The developer tools pane consists of several tabs but we will mainly use:
 
 ### Variable Declaration and Scope {#basics-var-scope}
 
-One significant way JavaScript differs from R is that variables must be declared using one of three keywords, `var`, `let`, or `const`, which mainly affect the \index{scope} where the declared variable will be accessible.
+One significant way JavaScript differs from R is that variables must be declared using one of three keywords, `var`, `let`, or `const`, which mainly affect the scope\index{scope} where the declared variable will be accessible.
 
 ```js
 x = 1; // error
@@ -389,7 +389,7 @@ x <- 2 # works
 
 Notably, `const` is mainly protecting yourself (the developer) against yourself; if something important is defined and should not change later in the code use `const` to avoid accidentally reassigning something to it later in the project.
 
-The `let` keyword is akin to declaring a variable with the `var` keyword. However, `let` (and `const`) will declare the variable in the "block scope." In effect, this further narrows down the scope where the variable will be accessible. A block \index{scope} is generally the area within `if`, `switch` conditions or `for` and `while` loops: areas within curly brackets.
+The `let` keyword is akin to declaring a variable with the `var` keyword. However, `let` (and `const`) will declare the variable in the "block scope." In effect, this further narrows down the scope where the variable will be accessible. A block scope\index{scope} is generally the area within `if`, `switch` conditions or `for` and `while` loops: areas within curly brackets.
 
 ```js
 if(true){
@@ -433,7 +433,7 @@ Accessing variables from the parent environment (context) is useful in JavaScrip
 
 ### Document Object Model {#basics-object-model}
 
-One concept does not exist in R is that of the "DOM" which stands for Document Object Model; this is also often referred to as the \index{DOM} tree (represented in Figure \@ref(fig:dom-viz)) as it very much follows a tree-like structure.
+One concept does not exist in R is that of the "DOM" which stands for Document Object Model; this is also often referred to as the DOM\index{DOM} tree (represented in Figure \@ref(fig:dom-viz)) as it very much follows a tree-like structure.
 
 ```{r dom-viz, fig.pos="H", echo=FALSE, fig.cap='Document Object Model visualisation'}
 diag <- DiagrammeR::grViz("
@@ -527,7 +527,7 @@ This, of course, only scratches the surface of JavaScript; thus, this provides a
 
 ## Shiny {#basics-shiny}
 
-It is assumed that the reader has basic knowledge of the \index{Shiny} framework and already used it to build applications. However, there are some more obscure functionalities that one may not know, but that becomes essential when introducing JavaScript to applications. Chiefly, how to import external dependencies; JavaScript or otherwise.
+It is assumed that the reader has basic knowledge of the Shiny\index{Shiny} framework and already used it to build applications. However, there are some more obscure functionalities that one may not know, but that becomes essential when introducing JavaScript to applications. Chiefly, how to import external dependencies; JavaScript or otherwise.
 
 There are two ways to import dependencies: using the htmltools [@R-htmltools] package to create a dependency object that Shiny can understand, or manually serving and importing the files with Shiny.
 
@@ -606,7 +606,7 @@ At this stage, we have made the JavaScript file we created accessible by the cli
 </html>
 ```
 
-In \index{Shiny} we write the UI in R and not in HTML (though this is also supported). Given the resemblance between the names of HTML tags and Shiny UI functions, it is pretty straightforward; the html page above would look something like the Shiny `ui` below. 
+In Shiny\index{Shiny} we write the UI in R and not in HTML (though this is also supported). Given the resemblance between the names of HTML tags and Shiny UI functions, it is pretty straightforward; the html page above would look something like the Shiny `ui` below. 
 
 ```r
 library(shiny)
@@ -621,7 +621,7 @@ ui <- fluidPage(
 )
 ```
 
-The \index{dependency} is used in the `htmltools::singleton` function ensures that its content is _only imported in the document once._ 
+The dependency\index{dependency} is used in the `htmltools::singleton` function ensures that its content is _only imported in the document once._ 
 
 Note that we use the `tags` object, which comes from the Shiny package and includes HTML tags that are not exported as standalone functions. For instance, you can create a `<div>` in Shiny with the `div` function, but `tags$div` will also work. This can now be applied to the Shiny application; the `path/to/script.js` should be changed to `files/script.js`, where `files` is the prefix we defined in `addResourcePath`.
 
@@ -695,7 +695,7 @@ dependency <- htmltools::htmlDependency(
 )
 ```
 
-About the above, the `src` argument points to the directory that contains the dependencies (`script` and `stylesheet`); this is done with a named vector where `file` indicates the path is a local directory and `href` indicates it is a remote server, generally a \index{CDN}. Note that one can also pass multiple `script` and `stylesheet` by using vectors, e.g.: `c("script.js", "anotherScript.js")`
+About the above, the `src` argument points to the directory that contains the dependencies (`script` and `stylesheet`); this is done with a named vector where `file` indicates the path is a local directory and `href` indicates it is a remote server, generally a CDN\index{CDN}. Note that one can also pass multiple `script` and `stylesheet` by using vectors, e.g.: `c("script.js", "anotherScript.js")`
 
 ```{block, type='rmdnote'}
 CDN stands for Content Delivery Network, a geographically distributed group of servers that provide fast transfer of dependencies.

3-20-htmlwidgets-intro.Rmd

@@ -6,11 +6,11 @@
 source("utils.R")
 ```
 
-This part of the book explores the integration of JavaScript with R using the \index{htmlwidgets} package, which focuses on libraries that produce a visual output. It is often used for data visualisation but is not limited to it.
+This part of the book explores the integration of JavaScript with R using the htmlwidgets\index{htmlwidgets} package, which focuses on libraries that produce a visual output. It is often used for data visualisation but is not limited to it.
 
-As in future parts of this book, we mainly learn through examples, building multiple widgets of increasing complexity as we progress through the chapters. Before writing the first widget, we explore existing R packages that allow creating interactive data visualisations as this gives a first glimpse at what we ultimately build in this part of the book. Then we explore JavaScript libraries that make great candidates for htmlwidgets and attempt to understand how they work to grasp what is expected from the developer in order to integrate them with R. Finally, we build upon the previous chapter to improve how htmlwidgets work with \index{Shiny}.
+As in future parts of this book, we mainly learn through examples, building multiple widgets of increasing complexity as we progress through the chapters. Before writing the first widget, we explore existing R packages that allow creating interactive data visualisations as this gives a first glimpse at what we ultimately build in this part of the book. Then we explore JavaScript libraries that make great candidates for htmlwidgets and attempt to understand how they work to grasp what is expected from the developer in order to integrate them with R. Finally, we build upon the previous chapter to improve how htmlwidgets work with Shiny\index{Shiny}.
 
-The htmlwidgets package originates from the rCharts [@R-rCharts] package created in 2012 by Ramnath Vaidyanathan. It brought together a plethora of data \index{visualisation} JavaScript libraries, datamaps, highcharts, morris.js, and many more. Though no longer maintained rCharts ultimately paved the way towards a framework for interactive visualisations in R: two years later, in 2014, Ramnath and other prominent R users start working on htmlwidgets.
+The htmlwidgets package originates from the rCharts [@R-rCharts] package created in 2012 by Ramnath Vaidyanathan. It brought together a plethora of data visualisation\index{visualisation} JavaScript libraries, datamaps, highcharts, morris.js, and many more. Though no longer maintained rCharts ultimately paved the way towards a framework for interactive visualisations in R: two years later, in 2014, Ramnath and other prominent R users start working on htmlwidgets.
 
 The objective of this chapter is to explore existing widgets available on CRAN, discover how they work, whilst focusing on their prominent features as we learn how to implement those in our very own widget in the coming chapters.
 

3-21-htmlwidgets-basics.Rmd

@@ -1,6 +1,6 @@
 # Basics of Building Widgets {#widgets-basics}
 
-Having explored existing packages that build on top of the \index{htmlwidgets} package gives some idea of the end product, but much of how it works and where to start probably remains somewhat mysterious. 
+Having explored existing packages that build on top of the htmlwidgets\index{htmlwidgets} package gives some idea of the end product, but much of how it works and where to start probably remains somewhat mysterious. 
 
 ```{r include=FALSE}
 source("utils.R")
@@ -26,7 +26,7 @@ Before going down the rabbit hole, let us explore the types of libraries you wil
 
 [Plotly.js](https://plotly.com/javascript/) is probably one of the more popular out there; it provides over 40 fully customisable chart types, many of which are very sophisticated. That is indeed the JavaScript library used by the R package of the same name: plotly.
 
-Looking at the code presented in the "Get Started" guide reveals just how convenient the library is. In Figure \@ref(fig:candidate-plotly) we import plotly, of course, then have a `<div>` where the visualisation will be placed. Then, using `Plotly.newPlot`, create the actual visualisation by passing it first the element previously mentioned and a \index{JSON} of options that describe the chart.
+Looking at the code presented in the "Get Started" guide reveals just how convenient the library is. In Figure \@ref(fig:candidate-plotly) we import plotly, of course, then have a `<div>` where the visualisation will be placed. Then, using `Plotly.newPlot`, create the actual visualisation by passing it first the element previously mentioned and a JSON\index{JSON} of options that describe the chart.
 
 ```html
 <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
@@ -57,7 +57,7 @@ Now let's look at how another popular library does it.
 
 ### Highchart.js {#widgets-basics-candidates-highcharts}
 
-[Highcharts](https://www.highcharts.com/) is another library that allows creating gorgeous \index{visualisation}, maps, and more; it's also very popular, albeit not being entirely free.
+[Highcharts](https://www.highcharts.com/) is another library that allows creating gorgeous visualisation\index{visualisation}, maps, and more; it's also very popular, albeit not being entirely free.
 
 ```html
 <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
@@ -130,15 +130,15 @@ Figure \@ref(fig:candidate-highcharts) is very similar to what plotly.js require
 knitr::include_graphics("images/candidate-chartjs.png")
 ```
 
-In Figure \@ref(fig:candidate-chartjs), we again observe a very similar structure as with previous libraries. The library is imported; instead of a `div` chart.js uses a `canvas`, the \index{visualisation} is also created from a single function which takes the canvas as first argument and a JSON of options as second.
+In Figure \@ref(fig:candidate-chartjs), we again observe a very similar structure as with previous libraries. The library is imported; instead of a `div` chart.js uses a `canvas`, the visualisation\index{visualisation} is also created from a single function which takes the canvas as first argument and a JSON of options as second.
 
 Hopefully, this reveals the repeating structure such libraries tend to follow as well as demonstrate how little JavaScript code is involved. It also hints at what should be reproduced, to some extent at least, using R.
 
 ## How It Works {#widgets-basics-inner-workings}
 
-Imagine there is no such package as \index{htmlwidgets} to help create interactive visualisations from R: how would one attempt to go about it?
+Imagine there is no such package as htmlwidgets\index{htmlwidgets} to help create interactive visualisations from R: how would one attempt to go about it?
 
-As observed, an interactive visualisation using JavaScript will be contained within an \index{HTML} document. Therefore it would probably have to be created first. Secondly, the visualisation that is yet to be created likely relies on external libraries; these would need to be imported in the document. The document should also include an HTML element (e.g.: `<div>`) to host said \index{visualisation}. Then data would have to be serialised in R and embedded into the document, where it should be read by JavaScript code that uses it to create the visualisation. Finally, all should be managed to work seamlessly across R markdown, \index{Shiny}, and other environments.
+As observed, an interactive visualisation using JavaScript will be contained within an HTML\index{HTML} document. Therefore it would probably have to be created first. Secondly, the visualisation that is yet to be created likely relies on external libraries; these would need to be imported in the document. The document should also include an HTML element (e.g.: `<div>`) to host said visualisation\index{visualisation}. Then data would have to be serialised in R and embedded into the document, where it should be read by JavaScript code that uses it to create the visualisation. Finally, all should be managed to work seamlessly across R markdown, Shiny\index{Shiny}, and other environments.
 
 This gives the basic diagram shown in Figure \@ref(fig:widget-inner-diagram); it will be broken down further in the next chapter as the first widget is built.