Rhino, the R package development framework created by Appsilon, has recently released two updates – versions 1.8 and 1.9. In this fireside chat, Kamil Żyła (one of the core developers of Rhino) and Marek Rogala (Appsilon’s Head of Technology) sit down to discuss these updates and the vision behind Rhino.

Watch the Full Interview

Marek: For those who haven’t tried it out yet, what exactly is Rhino?

Kamil: Rhino is an R package that you can install just like any other R package and start using right away. It’s best to think of it as a framework for your whole development process.

Rhino takes care of all the tools around software development that will help you maintain the best possible quality for your R applications.

You get a project structure and setup for all the tools needed for automation, so all those checks which Rhino provides can happen automatically without your input. It’s designed to help you build high-quality applications with all that setup coming out of the box, so you don’t need to worry about it.

Marek: What is the high-level vision of Rhino? How would you describe it?

Kamil: To understand the vision, it’s helpful to know how Rhino was born. It was created out of the need we had at Appsilon. We kept creating projects for our clients, and a lot of work was needed repeatedly.

We would set up a project with all the necessary tools, and this happened time and time again. We realized it would be great to create something so that we wouldn’t have to reinvent the wheel each time. The long-term vision now is to keep investing in improving Rhino based on our experience in projects and the things we are learning, so that it represents our best state of knowledge about how to develop Shiny applications well, with all the best practices.

Marek: Let’s discuss the new features in Rhino 1.8 and 1.9. First, tell us about box::linters.

Kamil: box::linters is a package that allows you to lint your R code for correct usage of the box package. Box provides a proper import system for R, similar to other modern languages. Many tools are not designed to work with box import statements, causing issues like the inability to lint for unused objects.

With time, we started working towards improving the situation and created linters specifically designed to work with the box package. As the idea matured and we added more linters, we realized it would make sense to create a separate package out of them. This is what box::linters is – a package that provides linters to automatically check how well you use box statements. Because it’s a separate package, you can also use it outside of Rhino.

The lintr package is the standard tool used for linting R source code, and it’s extensible. You can define new linters, and the box::linters package defines a couple of new ones specifically designed to work with box.

Marek: What about the improvements to GitHub Actions workflow triggers?

Kamil: This is a small change, but still quite helpful. A Rhino application comes with a GitHub Actions workflow that automatically runs all the linters and tests for the whole application.

Previously, it would trigger each time you push any code to your repository, which we figured is too much sometimes and doesn’t work that well with pull requests. We’ve made some improvements so that the tests only run when you open a pull request. This means that once you decide you want to see the checks run on your code, all you need to do is create a pull request from your branch, and you will have your checks. But it won’t happen on all the pushes to the repository, which can be a significant cost saver because running all these actions takes time.

Marek: So basically, I can imagine I’m working on some feature, and even before I share it with anyone, but I keep pushing the latest version of my changes, like new commits to some branch on GitHub, and each of those commits doesn’t trigger any run of all the checks and tests.

Kamil: Yes, unless you open a pull request, and then it will work like before. When the pull request is open, every push after that triggers a new run.

Marek: Coming to 1.9, you mentioned Sass integration. What was this change about?

Kamil: This is again a small addition, but one that makes things cleaner and more natural. Rhino comes with built-in support for writing custom Sass code. All you need to do is open a file, and you can start writing Sass.

Sass is an extension language for CSS, which gives you some really nice features and makes the development process much more pleasant. Rhino comes with built-in support for it. You just start writing that code, and with a single function, you can compile it into a nice minified file optimized for modern browsers. This file will be included automatically.

Typically, when you work with Shiny applications, the approach to styling will be to use some package which will do most of the work for you. There are many packages out there that do that, and one of them is bslib. bslib is actually used by Shiny underneath for its default appearance, but if you use bslib directly, you get access to much more capabilities. You get more components, you can style your application, add theming, and get access to the latest Bootstrap.

While you could use bslib without too much problem in Rhino before, the setup wasn’t that beautiful because it wasn’t working with custom Sass so well. The addition in Rhino 1.9 is a simple one. There’s a configuration file in Rhino that allows you to define how your Sass is built. A new configuration option called custom allows you to do it in your own way. You can bundle this custom Sass with the bslib theme.

Shiny will take care of the rest. That primarily means you can use variables you define for bslib in your custom Sass. But also, whatever you define in your custom Sass can be used with bslib. For example, you can override Bootstrap mixins if you wanted to. So you really get the best of both worlds and can customize it to the fullest extent you want.

Marek: So Rhino takes the assets from bslib and your custom assets and bundles them together instead of just bundling the custom assets. Is that how it works?

Kamil: Close, but not quite. Actually, the recommended approach now is to let bslib and the Sass package, which is used underneath for compiling Sass, handle your custom Sass for yourself.

Marek: And bslib, by the way, is like getting more mature, and I think it’s becoming a more mainstream approach to all Shiny applications.

Kamil: I think so, definitely. Now with the latest features of Bootstrap and bslib, you can do quite a lot of things that previously you’d have to search for a package to do for you. Like you’d use Shiny Dashboard. Now you have many functions for both defining your layout in the application and utilities like creating cards. So basically, you can build most of your UI using just bslib.

And then you can select a theme, which doesn’t lock you into one default appearance or force you into selecting some package based on what it looks like. You can select a theme for those components, and this makes it really quite customizable.

Marek: Right, so the last one was Prettier. What does this mean for us?

Kamil: Again, a brief introduction. Since the beginning, or at least since Rhino 1.0, we had linters for Sass and JavaScript. While these are not the technologies that you use that much in small Shiny applications, we learned that as the project progresses, typically you will need more customizations. And these are the technologies which are kind of the backbone technologies of the web. So we decided that you need the best tools for them as well.

From the beginning, we had linters for Sass and JavaScript. However, over the past couple of years, the landscape of tooling regarding Sass and JavaScript has changed in general. Now the linters generally focus more on detecting buggy or potentially incorrect code and less on code formatting. Instead, formatting is typically delegated to formatters. And here, Prettier is, I believe, the most popular formatter out there. So we decided to use that one. By running them, you can automatically format all your source files.

Marek: It definitely makes sense, especially since it was always a bit awkward because linters were checking also formatting rules, but then it was like duplicated responsibility, right? Because formatters also worked on the formatting, so it was always kind of weird. Before we wrap up, could you tell me, for someone who wants to try out Rhino, what would be the best steps to start?

Kamil: I think the best step would be to visit our website. You can find it by typing “Rhino Appsilon” in Google, and you’ll definitely get there. You can start trying it right away. The recommended way would be to just go to our website, install it, and start a new project.

First time using Rhino? Check out our step by step tutorial to help you get started.

Wrapping Up All You Need to Know about Rhino’s Updates

Rhino’s updates in versions 1.8 and 1.9 bring exciting improvements to the R package development experience. With features like box::linters, enhanced Sass integration, and Prettier formatting, Rhino continues to provide the best tools and practices for creating high-quality Shiny applications. If you’re interested in streamlining your R package development workflow, give Rhino a try!

Get the latest Rhino updates and everything Shiny delivered to your inbox. Subscribe to Shiny Weekly.

Resources: 

• Rhino GitHub Repository
• Rhino Documentation
• Boost Your Shiny App’s Code Quality with {box.linters} in {rhino} 1.8.0
• Rhino 1.9.0 Update on CRAN: New Formatting Tools and Cleaner {bslib} Integration

The post appeared first on appsilon.com/blog/.