Guten Tag!

Many greetings from Munich, Germany. Last time, we learned that it’s much more convenient to break down your app into very small modules. Apps that are built like that are simply easier to maintain. Making this work, though, is making sure that these small modules can pass information between them.

But this isn’t as easy as it might sound. Today, let’s have a look what can go wrong and how to avoid that. But first, time for my usual announcements.

Data cleaning fundamentals

As you know from yesterday’s announcement, Part 1 of my data cleaning master class was just released. But I wouldn’t be me if I didn’t release some freebies with that. That’s what you can get in my newest YT video. It shows you the 6 fundamentals Tidyverse functions you will need in every data project:

As always, all the code that you see in this newsletter can be found on GitHub.

A short example

Imagine that you have a Shiny app that contains the following parts:

1. A drop-down menu, and

2. a module that should take the selected item from the drop-down and create a chart based on this selection.

Here’s how the corresponding module looks:

Notice that the function that makes up the server contains another argument dropdown_choice that is passed to the module. This argument is used to determine what kind of chart is displayed. If you hard-code this argument inside the app server, then the corresponding chart is displayed.

Passing an input to the module

Next, let us bring our drop-down menu from the main app into the mix. You might be inclined to just replace the hard-coded part with the currently selected item in the drop-down menu.

But this won’t give you quite the results you’re looking for.

Passing changes

Unfortunately, when you load the app, everything seems to work out nicely. But when you try to change the value in the drop-down menu, you’ll notice that nothing reacts. It seems that the new information isn’t passed to the module.

The reason for that is that the code that generates the chart is only executed once. This happens because the value that is inside of input$dropdown is passed to the module at startup. But no mechanism is set up to update the chart when the value of input$dropdown changes.

The way to change that is to make the input argument for the server into a reactive. Instead of hard-coding a name that is passed, you’d need to add a reactive to this.

It’s important to note that you don’t want to pass the value that is inside the reactive to the module server function. Instead, you want to pass the reactive itself because the reactive will react to changes. If you pass the value, that value is used once and there’s still no mechanism for updates.

But in order for this to work you have to adjust your module server code such that it can work with a reactive.

Once you update your module server and your code in the app server, your changes should take effect. Hooray!

Using ReactiveValues()

In these kinds of scenarios, an alternative way is to use reactiveValues() instead of reactives.

That way, you can use a list-like syntax to access the values that you want to pass to the module. This might feel nicer compared to the ()-syntax.

More importantly, you can modify the reactive’s content and it’s nicer for testing small dummy app (for the modules) if you can assume that the inputs have a list-like structure.

With that, we have covered how to share data between modules in Shiny. Next week, we’ll move on to the Golem framework, which is a popular framework for creating large and robust Shiny apps. And if you have any questions, don’t hesitate to reply to this mail or contact me on LinkedIn.

See you next week,
Albert 👋

Enjoyed this newsletter? Here are other ways I can help you:

• My playlist on YouTube

• Free book: Yet Again - R + Data Science

• Free book: Beautiful tables with {gt}

• Blog posts