![]() This helps keep the server function focused on the big picture of reactivity, rather than the smaller details underlying each component.Published by onesixx on 17-05-16 17-05-16 Since this is now an independent function, it could live in its own file ( R/load_file.R, say), keeping the server() svelte. In this case, I’m still using validate() that works because outside of Shiny validate() works similarly to stop().īut I keep the req() in the server, because it shouldn’t be the responsibility of the file parsing code to know when it’s run. This isn’t a hard and fast rule sometimes it will make sense for your functions to input or output reactives.īut generally, I think it’s better to keep the reactive and non-reactive parts of your app as separate as possible. Instead, pass values into arguments and assume the caller will turn the result into a reactive if needed. When extracting out such helpers, avoid taking reactives as input or returning outputs. I recommend putting large functions (and any smaller helper functions that they need) into their own R/ There are two places you might put them depending on how big they are: ![]() That requires modules, which you’ll learn about in Chapter 19.īefore we go on to talk about exactly how you might use functions in your app, I want to start with one immediate benefit: functions can live outside of app.R. Once you’ve mastered the ideas in this chapter, the next step is to learn how to write code that requires coordination across the UI and server. The goal of this chapter is to activate your existing skills, showing you some specific cases where using functions can substantially improve the clarity of your app. I assume that you’re already familiar with the basics of functions 55. ![]() While you certainly can have one giant app.R file, it’s much easier to manage when spread across multiple files. Pulling out a reactive into a separate function, even if that function is only called in one place, makes it substantially easier to debug, because you can experiment with computation independent of reactivity.įunctions have another important role in Shiny apps: they allow you to spread out your app code across multiple files. In the server, complex reactives are hard to debug because you need to be in the midst of the app. Pulling out repeated code into a function reduces duplication (making it easier to update many controls from one place), and can be combined with functional programming techniques to generate many controls at once. In the UI, you have components that are repeated in multiple places with minor variations. This tends to have slightly different flavours for UI and server components: In this chapter, you’ll learn how writing functions can help. If you don’t take deliberate steps, the development pace of your app will slow, and it will become less and less enjoyable to work on. In turn, this makes it harder to add new features, and harder to find a solution when something goes wrong (i.e. it’s harder to debug). As your app gets bigger, it will get harder and harder to hold all the pieces in your head, making it harder and harder to understand.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |