Downloading data from shiny app issues

You can see the results after I uploaded a couple of puppy photos from Section 7. Figure 9. The accept argument allows you to limit the possible inputs. Section 8. Putting all these ideas together gives us the following app where you can upload a.

Again, the UI is straightforward: use either downloadButton id or downloadLink id to give the user something to click to download a file. The results are shown in Figure 9. You can customise their appearance using the same class and icon arguments as for actionButtons , as described in Section 2. Unlike other outputs, downloadButton is not paired with a render function.

Instead, you use downloadHandler , which looks something like this:. The job of this function is to create the name that will be shown to the user in the download dialog box.

The job of this function is to save the file in a place that Shiny knows about, so it can then send it to the user. This is an unusual interface, but it allows Shiny to control where the file should be saved so it can be placed in a secure location while you still control the contents of that file. The following app shows off the basics of data download by allowing you to download any dataset in the datasets package as a tab separated file, Figure 9.

One nice advantage of Google Sheets is that they are easy to access from anywhere; but unlike with databases, with Google Sheets data can be overwritten with multiple concurrent users. You can use the googlesheets4 package to interact with Google Sheets from R. Setup: All you need to do is create a Google Sheet and set the top row with the names of the fields.

You can do that either via a web browser or by using the googlesheets4 package. You also need to have a Google account. Now if you try to get R to write to a Google Sheet, R will ask for your permission explicitly every time. To learn how to add this authentication, refer to the package documentation.

If you have data that is not fully structured but is also not completely free-form, a good middle ground can be using a NoSQL database. NoSQL databases can also be referred to as schemaless databases because they do not use a formal schema.

NoSQL databases still offer some of the benefits of a traditional relational database, but are more flexible because every entry can use different fields. If your Shiny app needs to store data that has several fields but there is no unifying schema for all of the data to use, then using a NoSQL database can be a good option. You can use the mongolite package to interact with mongoDB from R.

To connect to the database you need to provide the following: db, host, username, password. When saving the data, mongolite requires the data to be in a data. Since there is no schema, it is not mandatory to create a collection before populating it.

Persistent storage lets you do more with your Shiny apps. You can even use persistent storage to access and write to remote data sets that would otherwise be too big to manipulate in R. The following table can serve as a reminder of the different storage types and when to use them.

Remember that any method that uses local storage can only be used on Shiny Server, while any method that uses remote storage can be also used on shinyapps. If you have questions about this article or would like to discuss ideas presented here, please post on RStudio Community. Our developers monitor these forums and answer questions periodically. See help for more help with all things Shiny. Shiny from. You will learn how to store: Arbitrary data can be stored as a file in some sort of a file system local file system , Dropbox , Amazon S3 Structured rectangular data can be stored as a table in a relational database or table-storage service SQLite , MySQL , Google Sheets Semi-structured data can be stored as a collection in a NoSQL database MongoDB The article explains the theory behind each method, and augments the theory with working examples that will make it clear and easy for you to use these methods in your own apps.

Local vs remote storage Before diving into the different storage methods, one important distinction to understand is local storage vs remote storage. Persistent data storage methods Using the above Shiny app, we can store and retrieve responses in many different ways.

Here is a summary of the different storage types we will learn to use. Local file system local The most trivial way to save data from Shiny is to simply save each response as its own file on the current server. Dropbox remote If you want to store arbitrary files with a remote hosted solution instead of the local file system, you can store files on Dropbox. Code: library aws. SQLite local SQLite is a very simple and light-weight relational database that is very easy to set up.

The basic parts of a Shiny app. How to get help. App formats and launching apps. Introduction to R Markdown. Introduction to interactive documents.

Setting Output args via Render functions. Generating downloadable reports. Shiny Gadgets. Reactivity - An overview. How to understand reactivity in R. Generating downloadable reports. Shiny Gadgets. Reactivity - An overview.

How to understand reactivity in R. Database basics - dplyr and DBI. Using the pool package basics. Using the pool package advanced. Using dplyr and pool to query a database. Persistent data storage in Shiny apps. Application layout guide. Build a dynamic UI that reacts to user input. Displaying and customizing static tables. How to use DataTables in a Shiny App. Help users download data from your app.

Help users upload files to your app. Interactive plots. Selecting rows of data. You can load the maps and mapproj packages in the normal way with. Shiny will execute all of these commands if you place them in your app. R script. However, where you place them will determine how many times they are run or re-run , which will in turn affect the performance of your app, since Shiny will run some sections your app. R script more often than others.

Shiny will run the whole script the first time you call runApp. This causes Shiny to execute the server function. Shiny saves the server function until a new user arrives. Each time a new user visits your app, Shiny runs the server function again, one time.

The function helps Shiny build a distinct set of reactive objects for each user. As users interact with the widgets and change their values, Shiny will re-run the R expressions assigned to each reactive object that depend on a widget whose value was changed. If your user is very active, these expressions may be re-run many, many times a second. Source scripts, load libraries, and read data sets at the beginning of app.

R outside of the server function. Shiny will only run this code once, which is all you need to set your server up to run the R expressions contained in server. These would be objects that you think each user will need their own personal copy of. This code will be run once per user. This can be quite often. You should generally avoid placing code inside a render function that does not need to be there.

Doing so will slow down the entire app. Copy and paste the following app. R file to your census-app directory. Then add.