[DRAFT] Shiny Reprex Guide


#1

Motivation - The goal of this document is to guide folks with #shiny issues through best practices for getting help from others.

This page is a wiki - If you have wiki-edit privileges and feel you can make a contribution, please do. All edits are version-controlled and tracked, so we can always step back any changes.

Your feedback - If you have a suggestion but don't want to edit, make a comment below.

Is linking to this document a good idea? - Probably not. Early on, this may be a disorganized list of desirables.


Shiny issues can be challenging to resolve relative to other problems with your code or statistical methods. Shiny apps are often large, complex projects with interacting files.

When seeking help from others it is considered polite to:

  • First, do your best to work through RStudio's debugging tools to diagnose your issue on your own. Often those shiny logs and tracebacks are useful to others trying to help out.
  • Second, strive to minimize the effort required to replicate your issue. You can do this with a shiny reprex (should we make shireprex a thing? "Shire-Prex"? no, probably not).

Shiny Debugging

Debugging Shiny applications

Something very light, geared towards new users?

Shiny Reprex

Guide to providing a minimal reproducible example for a shiny issue.

You're much more likely to get help if you have a minimal example which other people can copy and paste to see the same problem. When the code is minimal, it makes it easy for others to see where the problem is. And if the problem can be reproduced by copying and pasting, it makes it much easier for others to debug the problem.

If you don't know what part of your code is triggering the problem, a good way to find it is to remove pieces of code from your application, until the problem goes away. Once you've isolated the code that triggers the problem, you can go on to the next step.

To create a minimal example, you can go one of two ways: you can either keep removing code from your application until all the extraneous parts are gone, or you can construct a new Shiny application and copy the problem code into the new application. It's generally easier for others to understand the problem when you construct a new example, although either way is much better than not having a reproducible example at all.

Examples here...

Asking someone else for help means getting them up to speed about your shiny app and where your issue is likely to lie....


#2

I'm replying instead of editing as I'm not sure how to state this in the guide:

One pattern I see is learners have R that's not working and they have it all wrapped up in a Shiny app. I am of the opinion that the best way to get a working Shiny app is to get the basic logic working in R then (and only then) wrap the shiny bits around it. How can we tactfully (or not tactfully) encourage this and help a learner understand that by trying to debug basic R logic inside of a Shiny app is a very slow and hard way to learn R?