Suggestion on modules: When you get to them consider also the TidyModule approach

[D3SL]

Having read the first two parts of Reactivity Tips and Tricks I think you may like the TidyModule approach to modules more than stock. They use R6 class objects to hold both the UI and Server functions of a module as well and created a built in port system for piping data in and out of their modules.

If you're making apps with lots of repeated complicated code blocks it's imho a much better approach than stock modules, although if a majority of your app consists of individual bespoke pieces I'd just as soon skip the OO approach entirely. Sometimes all you want is a banana and not a gorilla troop factory to produce a stateful gorilla to hold the banana. Since we spend easily several times as much time reading code as writing it I'm a fan of balancing clever parsimony against clear legibility.

[ErdaradunGaztea]

Hey, thanks for your suggestion! I've read the vignettes and I like the idea very much, though I'm not the fan of using R6 accessors, they simply aren't intuitive to casual R programmers.

Aside from that, it got me thinking — how to do it better? And there are limitations that make it hard to come up with something simpler, since each module has to be placed somewhere in the UI and properly supplied with data through the server. I'd give it a shot with heavy use of {rlang}, but we've got many packages to write/update already :/

Sadly, we can't recommend {TidyModules} to others right now, as it is neither on CRAN (or Bioconductor) nor actively developed.