Week 12: Shiny, Part IV

Robert W. Walker

Overview

Overview

1. AMA
2. Shiny, Part IV: Best Practices
3. For Next Time: A Bit on Golem

The Assignment [Multi-week]

A shiny

Syllabus Module for Week 11

Chapter 16: Escaping the Graph

Video

The Case Studies

Part 1

Part 2

Two that are related.

Part 3

Part 4

The timer

Timer

Warnings:

It is quite easy to get carried away and muddle the flow.

Anti-patterns

The Path Forward

Shot of Final Section

The Overview

Best Practices

Two Word Summary: Software Engineering

Code Organization: - Clear and concise names - Comments for complex code - Can big functions be made smaller - Copy/paste and functions - Tangles versus isolations

Chapters 18 Functions and 19 [Modules] seek to achieve some of these ends.

Testing is Key

• renv or packrat for package dependencies
• config package for non-package dependencies

Testing ideas

Source Code and CI/CD

Github is most common for source storage though it is by no means the only such tool. Tools for integrating testing are the key to the CI/CD part.

Code reviews are common practice in professional development shops. Different approaches with different people often improve our code. Two aspects.

Benefits

Questions to Answer

Functions

Two Basic Types:

Functions for UI and Server

Why functions?

The key benefits of a function in the UI tend to be around reducing duplication. The key benefits of functions in a server tend to be around isolation and testing.

Shout out to golem

R packages have a standard form of organization with code in R/.

UI Functions

An example: - Copy/pasting sliders - A function for creating sliders - Functionally programming the sliders - The UI is data; functions given data

Server Functions

1. It is much easier to debug and test your code if you can partition it so that reactivity lives inside of server(), and complex computation lives in your functions.

2. When looking at a reactive expression or output, there’s no way to easily tell exactly what values it depends on, except by carefully reading the code block. A function definition, however, tells you exactly what the inputs are.

Let’s walk through the example.

Link

Shiny Modules

Modules are functions but, rather than being defined for a UI or server, they typically integrate both. They are essentially a namespace for their environment. They are basically mini-apps that define a module UI and a module Server.

The most basic module building

Interacting with namespacing

Modules are black-boxes that match together the UI and server. This means two important things.

1. Anything from outside the module has to be passed – think sandboxes.

Two Case Studies of Input/Output

The Case Studies

19.4 Provides Many Cases

An important part of the mental model.

Do not forget…

Chapter 20: Apps as Packages

First, this is the same advice as Emily Riederer’s advice on markdown-driven development.

Second, this requires knowledge of exactly how R packages are built. On R packages, there’s a great resource though more on this next time with golem [or the rhinoverse].

Testing

Four key levels:

Testing types

testthat

The structure of tests

When to test?

Three models

Security

Two main issues:

1. Your data: you want to make sure an attacker can’t access any sensitive data.

2. Your computing resources: you want to make sure an attacker can’t mine bitcoin or use your server as part of a spam farm.

An excellent talk:

Performance

This intro is perfect.

1. Benchmark
2. Profile
3. Optimise

Improvement Suggestions

There are two parts to improvement. The first is shared with essentially any R code using the three principles on the last slide: benchmark, profile, and optimise. Because shiny’s are whole systems, there is also…

1. Caching
2. Scheduling
3. Managing Expectations

You have now mastered shiny….