Fix punctuation typos across chapters

.github/workflows/build_bookdown_pr.yml

@@ -16,14 +16,14 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v4
 
       - uses: r-lib/actions/setup-r@v2
         with:
           crayon.enabled: 'FALSE'
           r-version: '3.6.1'
 
-      - uses: actions/cache@v2
+      - uses: actions/cache@v4
         with:
           path: ~/.local/share/renv
           key: ${{ runner.os }}-renv-${{ hashFiles('**/renv.lock') }}
@@ -36,7 +36,7 @@ jobs:
         uses: r-lib/actions/setup-tinytex@v2
 
       - name: Install sysreq
-        run: sudo apt update && sudo apt install -y gdal-bin git-core libcairo2-dev libgdal-dev libgeos-dev libgeos++-dev libgit2-dev libpng-dev libssh2-1-dev libssl-dev libudunits2-dev libxml2-dev make pandoc pandoc-citeproc zlib1g-dev libmagick++-dev libssl-dev libsasl2-dev
+        run: sudo apt update && sudo apt install -y gdal-bin git-core libcairo2-dev libgdal-dev libgeos-dev libgeos++-dev libgit2-dev libpng-dev libssh2-1-dev libssl-dev libudunits2-dev libxml2-dev make pandoc zlib1g-dev libmagick++-dev libssl-dev libsasl2-dev
 
       - name: Pulling hexmake
         run: docker pull colinfay/hexmake
@@ -52,7 +52,7 @@ jobs:
       - name: Render Book
         run: Rscript -e 'bookdown::render_book("index.Rmd")'
 
-      - uses: actions/upload-artifact@v2
+      - uses: actions/upload-artifact@v4
         with:
           name: _site
           path: _site/

.github/workflows/deploy_bookdown.yml

@@ -18,7 +18,7 @@ jobs:
     steps:
       - uses: actions/checkout@v4
 
-      - uses: actions/cache@v1
+      - uses: actions/cache@v4
         with:
           path: ~/.local/share/renv
           key: ${{ runner.os }}-renv-${{ hashFiles('**/renv.lock') }}
@@ -40,7 +40,7 @@ jobs:
         uses: r-lib/actions/setup-tinytex@v2
 
       - name: Install sysreq
-        run: sudo apt update && sudo apt install -y gdal-bin git-core libcairo2-dev libgdal-dev libgeos-dev libgeos++-dev libgit2-dev libpng-dev libssh2-1-dev libssl-dev libudunits2-dev libxml2-dev make pandoc pandoc-citeproc zlib1g-dev libmagick++-dev libssl-dev libsasl2-dev
+        run: sudo apt update && sudo apt install -y gdal-bin git-core libcairo2-dev libgdal-dev libgeos-dev libgeos++-dev libgit2-dev libpng-dev libssh2-1-dev libssl-dev libudunits2-dev libxml2-dev make pandoc zlib1g-dev libmagick++-dev libssl-dev libsasl2-dev
 
       - name: Pulling hexmake
         run: docker pull colinfay/hexmake
@@ -65,7 +65,7 @@ jobs:
       - name: Build redirect
         run: Rscript redirect.R
 
-      - uses: actions/upload-artifact@v1
+      - uses: actions/upload-artifact@v4
         with:
           name: _site
           path: _site/
@@ -79,9 +79,9 @@ jobs:
    needs: bookdown
    steps:
      - name: Checkout
-       uses: actions/checkout@master
+       uses: actions/checkout@v4
      - name: Download artifact
-       uses: actions/download-artifact@v1.0.0
+       uses: actions/download-artifact@v4
        with:
          # Artifact name
          name: _site # optional

.github/workflows/deploy_bookdown_wip.yml

@@ -13,26 +13,26 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v1
-      
-      - uses: r-lib/actions/setup-r@v1
+      - uses: actions/checkout@v4
+
+      - uses: r-lib/actions/setup-r@v2
         with:
           crayon.enabled: 'FALSE'
-          
-      - uses: actions/cache@v1
+
+      - uses: actions/cache@v4
         with:
           path: ~/.local/share/renv
           key: ${{ runner.os }}-renv-${{ hashFiles('**/renv.lock') }}
           restore-keys: |
             ${{ runner.os }}-renv-
-      
-      - uses: r-lib/actions/setup-pandoc@v1
-      
+
+      - uses: r-lib/actions/setup-pandoc@v2
+
       - name: Install tinytex
-        uses: r-lib/actions/setup-tinytex@master
+        uses: r-lib/actions/setup-tinytex@v2
 
       - name: Install sysreq
-        run: sudo apt update && sudo apt install -y gdal-bin git-core libcairo2-dev libgdal-dev libgeos-dev libgeos++-dev libgit2-dev libpng-dev libssh2-1-dev libssl-dev libudunits2-dev libxml2-dev make pandoc pandoc-citeproc zlib1g-dev libmagick++-dev libssl-dev libsasl2-dev
+        run: sudo apt update && sudo apt install -y gdal-bin git-core libcairo2-dev libgdal-dev libgeos-dev libgeos++-dev libgit2-dev libpng-dev libssh2-1-dev libssl-dev libudunits2-dev libxml2-dev make pandoc zlib1g-dev libmagick++-dev libssl-dev libsasl2-dev
 
       - name: Pulling hexmake
         run: docker pull colinfay/hexmake
@@ -54,7 +54,7 @@ jobs:
       - name: Render Book
         run: Rscript -e 'bookdown::render_book("index.Rmd", output_dir = "_book/wip")'
 
-      - uses: actions/upload-artifact@v1
+      - uses: actions/upload-artifact@v4
         with:
           name: _book
           path: _book/

02-planning-ahead.Rmd

@@ -13,7 +13,7 @@ Whatever your ambitions for your `{shiny}` application, you should take time tod
 A common thing you will hear about `{shiny}` is that it is a good prototyping tool.
 This cannot be denied.
 Building a Proof of Concept (PoC) for an app is relatively straightforward if you compare to what is needed to build applications in other languages.
-With `{shiny}`, you can build an "it works on my machine" web application in a couple of hours, and show it to your team, your boss, your investors.
+With `{shiny}`, you can build an "it works on my machine" web application in a couple of hours, and show it to your team, your boss, or your investors.
 Thanks to the way `{shiny}` was designed, you do not have to care about websockets, ports, HTML (HyperText Markup Language), JavaScript libraries, and all the things that are elegantly bundled into `{shiny}`.
 
 Hence, you can have a quick, hacky application that will work on your machine, and very rapidly.
@@ -31,7 +31,7 @@ The larger the codebase, the harder it is to untangle everything and make it wor
 In this book, we will present a framework called `{golem}`, which is a toolbox for building production-grade `{shiny}` applications.
 Even if `{golem}` is focused on production, there is no reason not to use it for your proof of concepts: starting a new `{golem}` project is relatively straightforward, and even if you do not use the advanced features, you can use it for very small apps.
 The benefit of starting straight inside a `{golem}` application really outweighs the cost.
-We hear a lot the question "When should I switch to `{golem}`?" The answer is simple: do not switch to `{golem}`, start with it.
+We often hear the question "When should I switch to `{golem}`?" The answer is simple: do not switch to `{golem}`; start with it.
 That way, you are getting ready for complexity, and if, one day, you need to turn this small app into a production app, the foundations are there.
 
 ### Develop with the KISS principle
@@ -85,10 +85,10 @@ The previous chapter introduced the notion of complexity in size, where the app
 
 Splitting a `{shiny}` project is made possible by following two methods:
 
--   **Extract your core "non-reactive" functions, which we will also call the "business logic", and include them in external files**, so that you can work on these outside of the app.
+-   **Extract your core "non-reactive" functions, which we will also call the "business logic", and include them in external files**, so that you can work on them outside of the app.
     Working on independent functions to implement features will prevent you from relaunching the whole application every time you need to add something new.
 
--   **Split your app into `{shiny}` modules**, so that your app can be though of as a tree, making it possible for every developer to concentrate on one node, and only one, instead of having to think about the global infrastructure when implementing features.
+-   **Split your app into `{shiny}` modules**, so that your app can be thought of as a tree, making it possible for every developer to concentrate on one node, and only one, instead of having to think about the global infrastructure when implementing features.
 
 Figure \@ref(fig:02-planning-ahead-1) is, for example, a representation of a `{shiny}` application with modules and sub-modules.
 You will not be able to decipher the text inside the node, but the idea is to give you a sense of how a `{shiny}` application with modules can be organized and split into smaller pieces that are all related to each other in a tree form.

10-step-by-step-build.Rmd

@@ -243,7 +243,7 @@ Continuous integration, on the other hand, is ensuring the software is still wor
 The idea is to add to the centralized version control system (for example, Git)[^step-by-step-build-6] a service like Travis CI, GitHub Action (if you are on GitHub), or GitLab CI (for GitLab) that runs a series of commands whenever something is integrated in the repository, i.e. every time a change to the codebase is made.
 In other words, every time a new piece of code is sent to the central repository, a service runs regression tests that check that the software is still in a valid, working state.
 
-[^step-by-step-build-6]: We will get back to version control in the Chapter \@ref(version-control), "Version Control"..
+[^step-by-step-build-6]: We will get back to version control in the Chapter \@ref(version-control), "Version Control".
 
 You can set up various continuous integration services automatically by using functions from the `{usethis}` package:
 

17-javascript.Rmd

@@ -54,8 +54,7 @@ It's important to note here that the **communication happens in both directions*
 In fact, when we write a piece of code like `sliderInput("first_input", "Select a number", 1, 10, 5)`, what we are doing is creating a binding between JavaScript and R, where the JavaScript runtime (in the browser) listens to any event happening on the slider with the id `"plop"`, and whenever it detects that something happens to this element, something (most of the time its value) is sent back to R, and R does computation based on that value.
 With `output$bla <- renderPlot({})`, what we are doing is making the two communicate the other way around: we are telling JavaScript to listen to any incoming data from R for the `id` `"bla"`, and whenever JavaScript sees incoming data from R, it puts it into the proper HTML tag (here, JavaScript inserts the image received from R in the `<img>` tags with the id `bla`).
 
-Even if everything is written in R, we **are** writing a web application, i.e..
-HTML, CSS and JavaScript elements.
+Even if everything is written in R, we **are** writing a web application—i.e., one built from HTML, CSS, and JavaScript elements.
 Once you have realized that, the possibilities are endless: in fact almost anything doable in a "classic" web app can be done in `{shiny}` with a little bit of tweaking.
 What this also implies is that getting (even a little bit) better at writing HTML, CSS, and especially JavaScript will make your app better, smaller, and more user-friendly, as JavaScript is a language that has been designed to interact with a web page: change element appearances, hide and show things, click somewhere, show alerts and prompts, etc.
 **Knowing just enough JavaScript can improve the quality of your app**: especially when you have been using R to render some complex UIs: think conditional panels, simulating a button click from the server, hide and show elements, etc.
@@ -64,9 +63,9 @@ All these things are good examples of where you should be using JavaScript inste
 Moreover, the number of JavaScript libraries available on the web is tremendous; and the good news is that `{shiny}` has everything it needs to bundle external JavaScript libraries inside your application.[^javascript-2]
 
 [^javascript-2]: This can also be done by wrapping a JS libraries inside a package, which will later be used inside an application.
-    See for example `{glouton}` [@R-glouton], which is a wrapper around the [`js-cookie` >https://github.com/js-cookie/js-cookie> JavaScript library.
+    See for example `{glouton}` [@R-glouton], which is a wrapper around the [`js-cookie`](https://github.com/js-cookie/js-cookie) JavaScript library.
 
-This is what this section of the book aims at: giving you just enough JavaScript knowledge to lighten your `{shiny}` app, in order to improve the global user and developer experience.
+This is what this section of the book aims to do: give you just enough JavaScript knowledge to lighten your `{shiny}` app, improving the overall user and developer experience.
 In this chapter, we will first review some JavaScript basics which can be used "client-side" only, i.e. only in your browser.
 Then, we will talk about making R and JS communicate with each other, and explore some common patterns for JavaScript in `{shiny}`.
 Finally, we will quickly present some of the functions available in `{golem}` [@R-golem] that can be used to launch JavaScript.

19-appendix.Rmd

@@ -477,7 +477,7 @@ Once this is done, we will create/update the `.dockerignore` file at the root of
     Removing the installation of `libgit2-dev` solved the issue.
 
 Inside our `Dockerfile`, we will also change the default repo to use <https://packagemanager.rstudio.com/all/latest>, which proposes precompiled packages for our system, making the installation faster.
-We will also add an installation of NodeJS, which is needed by our application..
+We will also add an installation of NodeJS, which is needed by our application.
 
 Then, we can go to our terminal and compile the image!