In episode 210 of the R Weekly Highlights podcast: The Positron IDE has officially been released after two years of intense development, and we share what excites us the most. Plus a new tool in your Shiny testing toolbox to bridge the gap between server-side and dynamic updating the user interface, and an entry point to making that URL of your Shiny app set inputs on the fly, a topic one of your hosts has been investigating for quite some time!
Episode Links
Episode Links
- This week's curator: Colin Fay - @[email protected] (Mastodon) & @colinfay.bsky.social (Bluesky) & @_ColinFay (X/Twitter)
- Announcing Positron, a new Data Science IDE
- {shinytesters}: Updating Inputs in testServer
- Adding Shiny app’s parameters to the URL
- Entire issue available at rweekly.org/2025-W34
- The Test Set Podcast https://posit.co/thetestset/
- Continue extension https://marketplace.visualstudio.com/items?itemName=Continue.continue
- shinytesters getting started vignette https://ashbaldry.github.io/shinytesters/articles/shinytesters.html
- Eric's shinystate R package https://github.com/rpodcast/shinystate
- Use the contact page at https://serve.podhome.fm/custompage/r-weekly-highlights/contact to send us your feedback
- R-Weekly Highlights on the Podcastindex.org - You can send a boost into the show directly in the Podcast Index. First, top-up with Alby, and then head over to the R-Weekly Highlights podcast entry on the index.
- A new way to think about value: https://value4value.info
- Get in touch with us on social media
- Eric Nantz: @[email protected] (Mastodon), @rpodcast.bsky.social (BlueSky) and @theRcast (X/Twitter)
- Mike Thomas: @[email protected] (Mastodon), @mike-thomas.bsky.social (BlueSky), and @mike_ketchbrook (X/Twitter)
- Cliff the Great Crusader - Suikoden - Trenthian - https://ocremix.org/remix/OCR01268
- Brinstar Bonsai Garden - Super Metroid - Red Tailed Fox - https://ocremix.org/remix/OCR01473
[00:00:03]
Eric Nantz:
Hello, friends. We are back of episode 210 of the Our Week of Highlights podcast. Yes. It's been the summertime. Our release release schedule has been a bit sporadic, but we're happy to be back this week nonetheless. And if you're new to the show, this is where we talk about the excellent highlights and other resources that are shared on this week's Our Weekly issue at ourweekly.0rg. My name is Eric Nance, and as always, life has never had a dull moment, especially lately. Lots of things happening in the day job and also my external efforts, and I'm actually just coming off of a very successful second annual r pharma gen AI conference that I get to edit the recordings of very soon. Well, lots of interesting talks there. But, yeah, I'm back here at the humble our weekly confines here, and I'm not joined alone. Thank goodness. I got my awesome cohost
[00:00:55] Mike Thomas:
virtually staring at me here, Mike Thomas. Mike, how are you doing today? Doing well, Eric. I know we have a strict policy of no free ads,
[00:01:03] Eric Nantz:
and there's somebody coming into the podcast space. But I did wanna shout out. Pauseit has a new podcast called The Test Set. It's pretty cool. They sure do. Yeah. We'll put a link to that in the show notes, and I've checked out the early episodes. And, yeah, I think they're on the right track and always excited to see more join us in the data science space, not just us by our lonesome here.
[00:01:25] Mike Thomas:
Absolutely.
[00:01:27] Eric Nantz:
Yes. And we got a fun I know we've haven't talked to each other in a bit. We got a lot to catch up on, but we're gonna use the highlights to do that as usual. And this week, our curator is the esteemed Colin Fay, author of the one of our favorite art packages of all time, Golem, amongst many of our great shiny initiatives. And as always, he had tremendous help from our fellow Aruku team members and contributors like all of you around the world with your poll requests and other great suggestions. And we lead off with more of a announcement of sorts, but one that's been almost two years in the making, but it is now official. We have mentioned before in previous highlights that Posit, of course, the company behind the very famous RStudio IDE, has been cooking in the oven, so to speak, a new IDE called Positron.
And as of about a week ago, it is now out of beta. It is officially released. The version one is out, and I have been an early adopter of Positron. I'll share my thoughts on that as we as we talk here. But if you haven't seen the beta and this is your first time hearing about Positron, what is it really about? Well, as you recall, perhaps from a couple years ago, maybe longer, time flies of course, our studio had rebranded themselves to be called Posit for many reasons, but one of which in particular was to emphasize that they are a multilingual data science, you know, tool, you know, maker in in this space.
And they've been diving into the world of Python quite a bit, and they had realized that RStudio itself, the ID, while it's been excellent for R users, certainly for other languages, it may have left a bit to be desired even with things like reticulate and whatnot. So part of their mission to become more multilingual was to reimagine the IDE, hence Positron was born. And what I can tell you is that it is going to look a lot different. If you're if you're used to our studio, it's gonna take a little bit of getting used to. However, there are definitely things that the team has done behind Positron to try and make that transition and custom customization ability a bit easier, especially if you're new to it for the first time.
And for those that aren't aware, Positron itself, while our studio had its own custom code base that Posit developed on, you know, standing on the shoulders of open source frameworks, of course, but really, it was their own their own making. Positron certainly is a highly engineered product, but we need to be clear here that it is actually a fork of another project called Code OSS, which is actually the underpinnings for Visual Studio Code. And we are seeing, I'd kid you not, Mike, a lot of companies and organizations forking the Versus Code code base and the code OSS, I should say, and putting their own opinionated spin on an IDE for their real particular domains.
Some of them are great. Some of them not so great, but I can tell that there's been a lot of time and effort put into the care and the development of Positron to make it not seem like literally just a reskin visual studio code. It definitely has a data science flavor. That's where you start to see things that are familiar to the RStudio experience, such as a data viewer, variables pane, being able to bring up help pages of, like, package functions and whatnot. But there are also many improvements over what you may have experienced in our studio. We don't have time to get into all of them today, but I really like the fact that I can switch our versions with a little drop down.
And there each of them are an individual process independent of the IDE's process. Whereas for our studio, it was all one major process, and if one thing went wrong, bye bye. You might see that little dialogue with a little bomb on there saying your session was aborted. Good luck to you. In not in not so many words. Here, if you do have an issue with pa of the r process or the Python process for that matter, you can just restart that console. It's not gonna break everything else. That to me is a huge quality of life feature right off the bat and to be able to go again back and forth between, say, running some code in r, maybe you have to switch to a Python script if you have a a team member or a project that's multilingual. You can go right there.
Use whatever flavor of notebook you like, whether it's Jupyter or, you know, I'm certainly on the chordal train. I've been doing a lot of chordal development in Positron. That's been a first class experience. Many of our nice enhancements associated with connecting the databases and also this is where you start to get into what the bet that they're hit hitching on so to speak of being on this fork of Code o s s, you get the ability to install extensions from the open VSX extension library. This is somewhat akin to if you're on a web browser such as a Chrome based browser, you have the extension, you know, ecosystem. You can make your browser do all sorts of things. Right? Well, positron is no different in that sense. You've got all these extensions available to you. So there's a lot that have been recommended out there in the community.
In fact, I remember it was Gary Gade and Bowie, Engineer Reposit that has kind of his own wrapper extension that does a lot of extensions that he finds very helpful in his development. So you see all sorts of these things out there, and it's just a click away really in the extension menu. So I really, really like that like that feature. So there are lots of other nuggets here, but there's also a nugget that I do wanna emphasize here. Not so much on the technical side, but on kind of the the life cycle of Positron going forward. It is open source.
The license, however, might be a bit different than what you're used to. This is called the elastic two point o source license. If this is your first time hearing it, I don't blame you because I didn't hear about this very much until recently as well. I won't try to pretend to be a a legal expert here. I mean, I don't don't go to me for legal advice, but I have a feeling this was chosen because there may have been situations where the Rstudio IDE, which was released on our more permissive license, was used in situations that maybe weren't quite as nice to posit or RStudio back then.
And I think they're trying to, if I had to guess, put a little bit of reins around just how positron is embedded in other services. That could be my speculation hat, but I think this is a reactionary measure to some stuff that has happened with the use of of our studio in other, I'll call it platforms. I am kind of biting my tongue here because I am recording this, but I have heard as much from some very trusted people in this space. So that caught my attention, but nonetheless, for an end user out there, a data scientist like yourself listening, no big deal. It's still open source. You can use that however many machines you like in your daily work. I've got it installed on both my work machine and my dev machine here. It's been working great, and I think the future is bright. And I dare say the timing of this probably is no coincidence that we're about a month away from Posikov, and I'm sure this was a a big feather to to shout out over there. But, yeah, Mike, exciting times. Positron's out of beta. What do you think?
[00:09:41] Mike Thomas:
Yeah. I'm very excited. And I think that whole elastic you know, the more that I'm reading up on it, that elastic license, mostly just means and I think this will be fine for pretty much everyone out there, that you can't, like, take positron and make it your own company's offering, like, turn it into some particular SaaS offering. And you're correct, Eric. I think we saw some instances of companies doing things like that, with the RStudio ID. So to me, I think it makes a lot of sense. You know, coming for soon for the the Posit workbench folks, which is exciting, exciting, you'll see Positron as a generally available IDE type. I'm imagining it was in pre preview for a little while, but for everybody out there, you'll be able to start using it, as your IDE of choice in Posit workbench if you like.
And one thing that I I did see in the article that I also liked was a sentence that said, we are committed to maintaining and updating our studio. So not just maintaining,
[00:10:41] Eric Nantz:
but also updating. That was a key find there. Yeah. It could have been easier to say maintain, keep the lights on, but they wanna keep improving it. Right.
[00:10:49] Mike Thomas:
So it's it's not like RStudio is getting deprecated. If you choose to continue using RStudio because that works best for you, then by all means, go ahead and do that. The positron assistant is very cool. It sounds like that's in preview. And the only thing I wonder there is if you can sort of bring your own LLM, like a local open weights model for privacy purposes, or if you have to use, like, a third party API. I'm assuming most of the docs point to the third party APIs. Yeah. As of now, I believe for co completion,
[00:11:21] Eric Nantz:
it's GitHub Copilot. And then for the agentic, you know, chat like interface, right now, it's Claude Anthropic. But I have heard from, you know, Joe Chang himself that they are looking at adding other providers, including bring your own model down the road.
[00:11:39] Mike Thomas:
Very cool. If, if Joe or anyone else is listening, you should check out the continue extension in Versus Code. It's it's really cool. It allows you to, you know, choose one of those providers or bring your own, local something that I'm actually giving a internal talk to our team today on how to configure that. Nice. Pretty exciting for privacy purposes, in some cases. Right? I think a lot of the times when I'm authoring code, it's not a big deal if if it's going back and forth to Claude or something like that. But if I'm asking it to reference a and use this context, like a proprietary document that, a client gave to us that has, you know, financial information or something like that on it, then I can't I can't do that. So I have would have to use a a local choice. And instead of having to, you know, spin up some sort of separate Ollama, it'd be nice to have that all sort of in that same UX.
So, just just rambling now. The continue extension allows you to do that, so maybe they can borrow some of that technology for Positron Assistant. And I think, you know, not to I think at, like, a higher level, just having everything ready to go for both R and Python is awesome. And you can't take that for granted. Like, that's not easy to do, to be able to just have in this particular IDE application just ready to go whether you wanna code up R or Python. There's for anybody that's either tried to install R or Python and and get packages and environments up and running and things like that, it's non trivial, especially if you're using the language that you're less familiar with. Right? If you're a Python user trying to start in our project or vice versa. And it may save you from also managing, like, a bunch of Versus Code extensions to have to do that.
[00:13:29] Eric Nantz:
If you're I can speak from experience trying to manage. You you recall, and others may be listening, I was an early adopter of the dev container setup and Versus Code and using the r extension a lot. And and they got me pretty far, but then when, like like you said, I had to go dive into either some Python coding or stuff, and it's like, oh my goodness. That is a lot to manage. So having, like, the batteries included, so to speak, as long as you've got R and Python available on your system, it's gonna hold your hand much easier than if you have to bring your own kind of dev setup with with Versus Code. So I do appreciate that quite a bit.
[00:14:07] Mike Thomas:
Absolutely. And I think, you know, one extension of that, no pun intended, is the database connection pane. Like, if I was to try to do that from Versus Code, I'd have to have a particular extension depending on what type of database I was connecting to. And I'm imagining in Positron, if you're using DBI or the pool package to manage your database connections, it doesn't matter if it's Postgres or a regular SQL Server or, you know, some some AWS, offering. If If you're, you know, leveraging those packages, then you should have this nice connection pane that will allow you to actually explore your database objects and and see that right in front of you, which is super cool. And then if you do wanna need to extend Positron, you can use any of those open VSX extensions, which is awesome. And and the last thing I think that's really helpful that speaks to my earlier point about having everything kind of ready to go for both r and Python is that there's, I think, ready made templates for UV and RN. And I think UV is kind of the leading virtual environment, manager for Python, and obviously RN, I think is still the big one on the R side. So I think that's possible, you know, to set up mostly through the UI instead of having to do, you know, pretty tricky, you know, command line, terminal type of stuff to get those environments up and running, which has been tricky for me in the past. And I know a lot of folks virtual environments are not fun. So anything that they can do to make that easier is awesome. So I'm very excited.
[00:15:34] Eric Nantz:
Yes. This boy, has that been a pain in my existence in years past. And one thing I've mentioned it before, but, boy, I I still have to give kudos for this. The very fact that I can just use a system wide install a positron on my setup, but yet have Nick's behind the scenes manage the R and Python installation, and it just works. Holy smokes. That is a game changer for me. It is very similar to what I felt with the dev container set up years ago. But now with Nyx, my goodness. It's the possibilities are almost endless. So I am definitely using that. And, I remember Bruno, once he shared that vignette on Rick's, oh, yeah. Positron. You just have to you have two ways of doing it. And I took the easy route, and boy, no easy route just works. So another another win for for for Positron on that sense. Because of RStudio, you have to actually install RStudio in that same Nix environment. That gets kinda tricky, especially if you're doing any WSL stuff like you have to do on Windows. So the fact that with this, that's all a thing of the past. Thanks to Positron and extensions. Yeah. That's a chef's kiss right there.
[00:16:46] Mike Thomas:
You'll be happy to know that in my slide on environment management for my Positconf talk this year, I discussed Posit workbench, dev containers, and nicks. I would never forget you.
[00:16:57] Eric Nantz:
Oh, my my heart flutters now, Mike. You know how to speak to me. Oh, I needed that this week. Well, since our esteemed, curator Colin Fay is at the helm here, it's no surprise that our next two highlights are definitely focused on the shiny space, and we're always happy to talk about that and some of the great, developments that are happening in the shiny ecosystem. And for this next highlight here, it is a new perspective and a new tool that is at our fingertips now for what can be a very difficult task of testing your Shiny app. We have covered in other highlights the the ecosystem around what Shiny has built in to help you test what you might call the server side logic of certain pieces of your app, including modules, which can get you pretty far.
And where it does not get you as far potentially is if you have a shiny server side process and say a module or elsewhere where it's not just the ReactOS from a classical set your input and, you know, the ReactOS downstream, whether it's a reactive dataset or a reactive plot or what have you, It just works to bring all that together in in the the way you do shiny testing in basic shiny itself would test that, you have a test server function that can help you along the way. What happens though if your logic also has a lot of interesting UI updates dynamically on server side via the update family of functions, or maybe you wanna update that value in the drop down, that value in the date picker and whatnot. It wasn't so trivial to accomplish that with kind of this test server framework. Well, there is a new package to address this very need, and this package is called Shiny Testers and has been authored by Ashway Baldry, who is a senior data scientist at Ascent over in The UK.
And and I'm I wanna say right off the bat, Ashway is not new to the shiny space. He has made a few, very novel contributions, and we'll have a link to his, kind of portfolio open source page in the show notes. There's a lot of great finds there that I'm gonna be looking at. In particular, he made a a module called designer It was like a an attempt at wireframing Shiny apps, which is pretty intriguing back in the day. Back to the the task at hand here, he has written Shiny testers to be kind of this one call kind of function in your test server logic that if you have any part of your server side process that does this updating of an input, which then, of course, would feed into additional reactives, you can incorporate all this with literally one function call called use Shiny Testers in the body of your test that function or test that test, I should say, that's leveraging kind of what Shiny does for the test server paradigm.
And if you have any in your UI of the app, any of these update, you know, any inputs that need updating in your test, you have, like, say, an update date input, it's just gonna magically work the way you would expect about you writing custom code. And if you want to attempt this before, that's where I also have a link to the the github repository of the package itself in particular the package documentation. In the getting started vignette in particular which we'll link to, he shows what that custom code would look like using a combination of our lang kind of like dynamic expression, you know, inserting that this package is gonna let you kinda have free of charge with just that use Shiny Tester. So in the example on the blog post here, he's got an observer, an observe event that's based on a button press that's gonna update a date input with a new value, maybe a new minimum value.
And then in the body of the test server you've got session dollar sign set inputs a way to, in essence, change the input values based on that. And then he also sets the input for the, I guess, the action button that's being pressed. And then once that happens, then he's able to simply check then at that point, does that input value equal what it should equal after that observe event? I admit I I will have to sit down with this a little bit, but I definitely do have some apps at my in my current, day job projects where I am updating observe updating via observe events certain inputs based on other choices that the user has made in the app or other downstream reactives that have happened in the processing.
So there's a lot going on under the hood here, but I think the key takeaway is you as the end user, if you wanna stick with kind of this test server paradigm of testing kind of the the behind the scenes of your shiny UI, but yet still wanna be able to dynamically update these inputs. It does sound like ShinyTesters is a way to scratch that particular need and to have a pretty elegant way of doing it. So it is still in GitHub. I believe he's playing the release of the CRAN in the near future, but certainly I am more than happy to have another, tool in the testing space in my toolbox that can be less of a footprint, so to speak, than the full blown, say, say, shiny test two suite of the whole dynamic, you know, Chrome process that's manipulating inputs. This is kinda getting you there almost all the way. So Mike is smiling here. He's got a lot to say here. Let's hear it.
[00:23:18] Mike Thomas:
No. I don't wanna talk about headless Chrome right now. I fought headless Chrome last night. Oh, okay. Five hours. Sorry for the bad bad memories there. No. No. No. It's okay. I did figure If anybody is trying to use types and Mermaid JS in a dev container, anybody sits at the intersection of those three things. I'm I'm here to help. I figured it out. No doc. You'll find a way to contact Mike in the show notes because there's a lot of you out there, I'm sure. Yes. Mermaid JS does not like, Mermaid JS in quarto does not like Docker. And they put that in the documents, in the the quarto docs. But, anyways, I digress. This sounds like, you know, as you mentioned, Eric, a way to do some Shiny testing, particularly across these update family functions without needing, you know, the the headless Chrome and and everything that goes along with that for Shiny test two. And I think that that's really powerful, potentially.
You know, one of the interesting things in the example implementation is there's kind of an entire server function stuck in the test that code. And I'm imagining that for the purposes of, like, reproducibility and as the app changes, you're not going to want that to be the case. You're going to actually want that function defined elsewhere, you know, in your R directory, and then be able to leverage it within your test that suite here, and probably still have your, shiny, you know, colon colon test server function in the second half of this this test that function. And I know this is probably difficult to articulate on a podcast, but it's it's fairly straight forward, this example implementation. If you take a look at the the blog post and sort of the first snippet of code example that's been put in there. And very, very easy to to do things like within tests that, you know, expect identical between, a particular hard coded date that you might have and the update that you're trying to push.
And, I think it's very obvious, very straightforward in its implementation. And we use, at Catchbook, the update family of functions constantly all the time, and I'm sure you do, Eric. If you are out there using a lot of render UI, you're making your app slower and clunkier than it needs to be. That's all I'll say. Eric and I could do a whole hour long podcast
[00:25:49] Eric Nantz:
about why that's the case and why you shouldn't do that. We have definitely touched on in our previous workshops too. I remember very well. Yep.
[00:25:56] Mike Thomas:
People are like, why? It's it's it's using, you know, overhead that doesn't need to be used, when this update family of functions exists. And a lot of people that I run into don't even know that that update family of functions exists, and it's it's life changing. It certainly was for me when I figured it out. So having sort of this testing format against those update functions, again, that we're using constantly, I think is is really helpful. Excited to see how this package progresses and ideally makes it to CRAN in the near future.
[00:26:27] Eric Nantz:
Yes. I'll be watching this space quite a bit, and I do have a, yeah, a couple of day time or day job, I should say, projects where, very, you know, complex shiny app that we're developing. We're We're getting into that testing phase. And no, I was not a good boy, Mike. I didn't build my test right away. I do have to bolt them on, but this gives me gives me kind of a way out of the, you know, I I hate saying it because Barish Swirk is a good friend of mine, but shiny test two is is sometimes a hammer that doesn't need to be the hammer if you can accomplish a lot of it. In a, if you're doing what we Mike and I would call the quote, unquote right way of having your business logic and fit for purpose functions that you can do and test that out alone, go for it. That's awesome. Maybe even a dedicated package, even better. But then when you do add that in between state of the app is doing something, it's probably calling a lot of functions you've built outside of, you know, Reactors or whatnot, but you still need some way to test kinda that cohesive experience with the dynamic UI updating that you're doing in the more logical and and more performant way with the update family. I think this is this is massive. So it flew under the radar, certainly. That's why we love doing our weekly. I would not have known about this probably otherwise, until maybe a random crayon, you know, message. But this is I'm gonna be playing with this probably in the coming weeks and, yeah, not a moment too soon.
And rounding out our highlights today, we've got another awesome shiny post about a feature that definitely does not get a lot of attention, and I definitely share, you know, the the same, sentiments of the author here of trying to get the word out there in many different ways. But our last highlight comes from Mauricio Pacho Vargas, and he is definitely not a stranger to the r community, and and he's been around quite a bit with many contributions actually in the c plus plus space amongst many other improvements. But he talks about Shiny in his, blog post here in the highlights about a a very neat trick that you can do to help ingest kinda new parameter values in a typical Shiny application via parameters to the URL.
Now what this might mean if you're thinking about what do you mean parameters in URL, I just go to a web page and it just works. Right? Sometimes depending on the page you go to, especially if it's more of a classically designed page, you might wanna try looking at what happens after the .com or this, you know, the the the TLD domain at the end. You might see a slash and then you might see what looks kinda like key value pairs or you might say some value or some name of a variable equals some, like, number or some really random string, and you might see a few of those separated by an ampersand.
Those are what we mean by URL parameters. And the default invocation of Shiny, you don't necessarily get that, you know, right away. You have to kind of build that in. How do you build that in you ask? And that's where the blog post comes in with one way of doing it. And, and, Pacho demonstrates this via a golem, you know, app, which again, you know, big props on that. We are all big fans of golem here as well as our curator, of course. And this is tapping into a feature that I think deserves more attention. I have more to say about that shortly of bookmarkable state, but there are different flavors of doing that. So in the flavor of this example here, we got a very simple, server app, which I think has only a a couple inputs, for the UI.
And then in order to register an app for a bookmarkable state here with the URL parameters, you first have to figure out how do you trigger this. And there are different ways of triggering, like, the act of generating these parameters or these values. In here, he's just using a simple observe block that is gonna change after every input change. And now that might be too greedy to some, but it it definitely works here in this, tutorial like example, converting the input object to a list via the reactive values to list, and then making sure he excludes an input that he doesn't care about. So you can give it the input ID of a input you don't want in this URL parameter and with the set bookmark exclude function. And then when you do that, the next call is just simply session dollar sign do bookmark. That's gonna help register these parameters.
And then the on bookmarked function, that's kind of a callback function of sorts. He is then I dynamically updating the URL that's gonna have these URL parameters baked in after that operation. And then in the UI UI of the of the app, it's very straightforward. It looks like a typical Shiny app with a sidebar layout, three select inputs, one main panel, and then a slider input. And then the key part is that you have to wrap this It's a the typical Shiny app UI function. You have to make it a function with the request parameter as its default, you know, you know, per one parameter, but then the rest of it is simply a tag list of the rest of the rest of the elements.
And with that, just some more Golan magic there behind the scenes, and then you can run the app. And then when you run it, and he has an example at the end of the post here, the URL has got kinda that local host URL, but then there's a slash question mark underscore inputs and then we start to see what the actual values are where it's maybe like for the species. It's the when the penguins say you set the idyllis, you know, species. The island, you can Bisco, I believe. But you'll notice that if the text has some kind of special character in it, in the URL parameters they have to do this fancy percent number to encode a a special character, I believe. Something like that. I'm not an expert on that side of it.
And that can get you really far. That can get you really far for these simpler apps. However, I will mention you might hit your limits on some of this, especially if your app has a lot of inputs that you want as a parameter. Because even though I have seen some really long URL strings in some of the apps I visit in the day to day, whether shiny or not, There actually is a limit to how long that address string can be, and you might find out the hard way if you use this URL parameter method for an app that has more than maybe a couple of modules of a lot of inputs inside.
So, there is another path forward, which I'll get to shortly. But first, Mike, what do you think about these, techniques here?
[00:33:49] Mike Thomas:
I think this is really helpful introduction for folks who are looking to get into bookmarking, particularly if you are using, Gollum. And, specifically, you know, there's I'll be honest. I haven't done a lot of bookmarking. I I should have, but we just haven't for whatever reason. And I think most of these bookmark, functions are sort of Shiny out of the box functions like set bookmark exclude, the session dollar sign do bookmark, and then the the on bookmark and update query string. Are those all pretty much native to to Shiny? Exactly right. Yep. So we're not using anything, you know, any crazy, additional packages. This is all sort of native technology, which is great. You know, one thing that was interesting to me as well, especially as you talk about, having query strings that are or URLs, I should say, that get really long really quickly is this function called set bookmark exclude.
So you're able to actually take the names of one of your input IDs that you have and just use that within double quotes within the set bookmark exclude, function here and ensure that that particular input widget, whatever it may be, is not used in the bookmarking function at all. So I would imagine if you sort of send this URL to somebody else who wants to access the app, you know, whatever you have that widget set to will not be sort of captured for them when they go to, you know, enter that URL in their own browser, which I think is is very helpful in situations where you have a ton of inputs but you only care about sharing the state of one particular input in your app. So that was something that I learned that I think is really useful. If you're coming from, you know, the Gollum world and you take a look at the code here that Pacha has in the blog post, I don't think it's very intimidating at all. One great catch, Eric, that I didn't catch the first time around, as you mentioned, is in the app UI code, which is a function sort of like everything in Gollum, it needs to take a parameter now called request.
So I think that's, you know, something that's easy to miss in this blog post that I think is critical to making this all work. But as you mentioned, Eric, these URLs can get real long real quick if you have multiple modules, multiple inputs, things like that. You have any, you know, additional reading material that we could brush up on on this topic?
[00:36:18] Eric Nantz:
I dare say so. I have been in this space for a bit, and I have fought these battles the hard way a lot of times. And for those that aren't aware, Shiny bookmarkable state, what we have here is one flavor of it, the URL flavor of it. There is another flavor of it that is definitely more akin to more complex applications overbuilt with golem or not, and that is called server side bookmarking. That is where instead of the URL being updated that you could copy paste and send it to your your colleague or your customer, for replicating a certain situation of the of the app UI, you actually would save the state of the app via the inputs and any reactives that you think are important enough. There's a way to do that as well. But it gets saved on the server process, which is either a local directory on your file system if you're running this in a vanilla, like, posit workbench, positatron, or r studio session on your computer.
But if you are the using this on, say, a posit connect server or a shiny server pro back in the day, these server side bookmarkable state files would be saved in some kind of cryptic area on the server that only an admin could have access to. That might be fine for or a lot of use cases. But for me, it wasn't quite because I wanted my app users to be able to access these objects that are saved with bookmarkable say, especially some of these reactives that I saved out and these input values into other situations. So it all so this is all culminated with what I will be talking about at POSITCONF, my new r package called shiny state.
I won't say I have the most creative naming, chops in the world, but nonetheless, this is a a kind of supercharged version of bookmarkable state where I'm gonna put the power of where you store these bookmarks in your hands, Mike, because with shiny state, I'm gonna let you tap into the power of the pins package and let you choose where those bookmarkable state files are sent and open the door for many possibilities that the default bookmarkable state feature doesn't quite allow for, including the ability to share perhaps a bookmarkable session with your teammate, maybe your colleague that's using the same app, and you can, in essence, collaborate on, application experience together.
It won't be quite like a Google Doc thing, but it'll be much closer than you get in the vanilla shiny bookmarkable state. So, which I got joked to many times, this is very much a conference driven development paradigm. I've got the the package on GitHub, and I'm putting my talk together for positconf, but this has been a huge this this, paradigm that I've put in shiny state has been custom code for a very long time in my one app to another kind of copy paste this stuff and you know, Hadley's in my ear at the moment saying if you're doing that three or four times, that's gotta be a function. Well, it was a function, but I kept doing that three or four times in many different apps. So it was like, make it a package in my head. So, yep, that's why shiny state exists. And I'm really excited to see others try it out. Very early days, but I think it shows great promise. And, like I said, the power is in your hands for Hayutayor Bookmarkable State. And I'm really excited to see where it goes.
[00:40:02] Mike Thomas:
No. We're extremely excited for, your talk and the the shiny state package that I know you've worked super hard on. And I think parlays with this blog post,
[00:40:10] Eric Nantz:
Bipasha really nicely depending on how complex your use case is here. So great way to round out the highlights this week. And I dare say, I'm, I've been to I've been very fortunate. I've been to every iteration of our studio in Posikov. I don't think the book marketable state feature has ever been mentioned once. That is how under the radar that has been, but those of us in the in the industry are consulting trenches. Boy oh boy, it's been a valuable thing, and I think once hopefully, the shiny state kinda takes off, then yeah you might find some interesting you know uses of this mic and you of all people I think will appreciate what what is in potential here for using this
[00:40:54] Mike Thomas:
absolutely gotta get this thing on crayon though because there's a couple other shiny states packages floating around on GitHub. Oh, really? Well Watch out. Watch out. Okay. That's good to know now. Maybe I should have known that sooner. Nonetheless, the name of it is Sorry. Most of them, don't look to have any activity in, like, the last three years. Okay. Well,
[00:41:14] Eric Nantz:
yeah. Like I said, I'm in the conference driven development mode. I do want this thing on Kranos sooner or later, so that will be another journey. But we hope that our weekly helps of your journey in data science, especially the use of R and open source in your data science journey. Every week. Tons of fantastic resources. We obviously can't get to the entire issue. We'd be here for almost five hours if we did. But nonetheless, that is for you all to catch up on after this episode. You can see all the excellent, you know, links Colin Fay has shared with us on this week's issue. And, of course, this is a community project. This isn't like some of those things you might see on, cough, cough, LinkedIn, where they're doing their own fangled newsletter of sorts about the r space. This is a community driven effort.
I I do throw a little shade there. I couldn't resist because I'm very proud of where r weekly stands in in the in the statuary community. Certainly, some talks that use r really inspired me to say that because r weekly has had a hand in some really interesting community efforts recently that I heard about. But we are also driven by your support too in keeping the project going. Best way of doing that is to share those great resources you found, blog posts, new package, maybe a new thing on GitHub you discovered that's really interesting. Our curator will be glad to contribute that into the next issue. We're just a pull request away. Everything on GitHub, everything transparent.
Absolutely love it. And also, we love hearing from you too. We are available on our, first, our podcast page that you get in the podcast player. We have a link to the contact page. Definitely send us feedback there. It's always much appreciated. If I bumble something, especially your pronunciations, boy, I need to hear about it because I'm not the greatest of speaking names. But, also, we love hearing from you about our feedback on social media. I am at [email protected] on Blue Sky. I am also on Mastodon with that our podcast at podcast in this house social, and I'm on LinkedIn. Definitely not causing any weird posts there. Just some fun things here and there. Mike, where can the listeners find you?
[00:43:28] Mike Thomas:
You can find me on blue sky as well at mike dash thomas dot b s k y dot social Or on LinkedIn, if you search Ketchbrooke Analytics, k e t c h b r o o k, you can see what I'm up to.
[00:43:40] Eric Nantz:
Very nice. And I just saw I think it was a week or so ago. Your team is expanding once again. Got some great new talent coming on your team. It's always great to see your your humble little, consulting shop grow and not so little anymore, is it? You got a lot going on there.
[00:43:56] Mike Thomas:
Thank you very much. No. Very exciting and open source all the time.
[00:44:00] Eric Nantz:
That's the way we love it. Yep. So with that, we will close-up shop here on episode 210 of our weekly highlights. There may or may not be an episode because both of us have a lot of things going on next week, but we'll see what happens. Either way, we hope to see you back here for another episode of our weekly highlights either next week or soon after.
Hello, friends. We are back of episode 210 of the Our Week of Highlights podcast. Yes. It's been the summertime. Our release release schedule has been a bit sporadic, but we're happy to be back this week nonetheless. And if you're new to the show, this is where we talk about the excellent highlights and other resources that are shared on this week's Our Weekly issue at ourweekly.0rg. My name is Eric Nance, and as always, life has never had a dull moment, especially lately. Lots of things happening in the day job and also my external efforts, and I'm actually just coming off of a very successful second annual r pharma gen AI conference that I get to edit the recordings of very soon. Well, lots of interesting talks there. But, yeah, I'm back here at the humble our weekly confines here, and I'm not joined alone. Thank goodness. I got my awesome cohost
[00:00:55] Mike Thomas:
virtually staring at me here, Mike Thomas. Mike, how are you doing today? Doing well, Eric. I know we have a strict policy of no free ads,
[00:01:03] Eric Nantz:
and there's somebody coming into the podcast space. But I did wanna shout out. Pauseit has a new podcast called The Test Set. It's pretty cool. They sure do. Yeah. We'll put a link to that in the show notes, and I've checked out the early episodes. And, yeah, I think they're on the right track and always excited to see more join us in the data science space, not just us by our lonesome here.
[00:01:25] Mike Thomas:
Absolutely.
[00:01:27] Eric Nantz:
Yes. And we got a fun I know we've haven't talked to each other in a bit. We got a lot to catch up on, but we're gonna use the highlights to do that as usual. And this week, our curator is the esteemed Colin Fay, author of the one of our favorite art packages of all time, Golem, amongst many of our great shiny initiatives. And as always, he had tremendous help from our fellow Aruku team members and contributors like all of you around the world with your poll requests and other great suggestions. And we lead off with more of a announcement of sorts, but one that's been almost two years in the making, but it is now official. We have mentioned before in previous highlights that Posit, of course, the company behind the very famous RStudio IDE, has been cooking in the oven, so to speak, a new IDE called Positron.
And as of about a week ago, it is now out of beta. It is officially released. The version one is out, and I have been an early adopter of Positron. I'll share my thoughts on that as we as we talk here. But if you haven't seen the beta and this is your first time hearing about Positron, what is it really about? Well, as you recall, perhaps from a couple years ago, maybe longer, time flies of course, our studio had rebranded themselves to be called Posit for many reasons, but one of which in particular was to emphasize that they are a multilingual data science, you know, tool, you know, maker in in this space.
And they've been diving into the world of Python quite a bit, and they had realized that RStudio itself, the ID, while it's been excellent for R users, certainly for other languages, it may have left a bit to be desired even with things like reticulate and whatnot. So part of their mission to become more multilingual was to reimagine the IDE, hence Positron was born. And what I can tell you is that it is going to look a lot different. If you're if you're used to our studio, it's gonna take a little bit of getting used to. However, there are definitely things that the team has done behind Positron to try and make that transition and custom customization ability a bit easier, especially if you're new to it for the first time.
And for those that aren't aware, Positron itself, while our studio had its own custom code base that Posit developed on, you know, standing on the shoulders of open source frameworks, of course, but really, it was their own their own making. Positron certainly is a highly engineered product, but we need to be clear here that it is actually a fork of another project called Code OSS, which is actually the underpinnings for Visual Studio Code. And we are seeing, I'd kid you not, Mike, a lot of companies and organizations forking the Versus Code code base and the code OSS, I should say, and putting their own opinionated spin on an IDE for their real particular domains.
Some of them are great. Some of them not so great, but I can tell that there's been a lot of time and effort put into the care and the development of Positron to make it not seem like literally just a reskin visual studio code. It definitely has a data science flavor. That's where you start to see things that are familiar to the RStudio experience, such as a data viewer, variables pane, being able to bring up help pages of, like, package functions and whatnot. But there are also many improvements over what you may have experienced in our studio. We don't have time to get into all of them today, but I really like the fact that I can switch our versions with a little drop down.
And there each of them are an individual process independent of the IDE's process. Whereas for our studio, it was all one major process, and if one thing went wrong, bye bye. You might see that little dialogue with a little bomb on there saying your session was aborted. Good luck to you. In not in not so many words. Here, if you do have an issue with pa of the r process or the Python process for that matter, you can just restart that console. It's not gonna break everything else. That to me is a huge quality of life feature right off the bat and to be able to go again back and forth between, say, running some code in r, maybe you have to switch to a Python script if you have a a team member or a project that's multilingual. You can go right there.
Use whatever flavor of notebook you like, whether it's Jupyter or, you know, I'm certainly on the chordal train. I've been doing a lot of chordal development in Positron. That's been a first class experience. Many of our nice enhancements associated with connecting the databases and also this is where you start to get into what the bet that they're hit hitching on so to speak of being on this fork of Code o s s, you get the ability to install extensions from the open VSX extension library. This is somewhat akin to if you're on a web browser such as a Chrome based browser, you have the extension, you know, ecosystem. You can make your browser do all sorts of things. Right? Well, positron is no different in that sense. You've got all these extensions available to you. So there's a lot that have been recommended out there in the community.
In fact, I remember it was Gary Gade and Bowie, Engineer Reposit that has kind of his own wrapper extension that does a lot of extensions that he finds very helpful in his development. So you see all sorts of these things out there, and it's just a click away really in the extension menu. So I really, really like that like that feature. So there are lots of other nuggets here, but there's also a nugget that I do wanna emphasize here. Not so much on the technical side, but on kind of the the life cycle of Positron going forward. It is open source.
The license, however, might be a bit different than what you're used to. This is called the elastic two point o source license. If this is your first time hearing it, I don't blame you because I didn't hear about this very much until recently as well. I won't try to pretend to be a a legal expert here. I mean, I don't don't go to me for legal advice, but I have a feeling this was chosen because there may have been situations where the Rstudio IDE, which was released on our more permissive license, was used in situations that maybe weren't quite as nice to posit or RStudio back then.
And I think they're trying to, if I had to guess, put a little bit of reins around just how positron is embedded in other services. That could be my speculation hat, but I think this is a reactionary measure to some stuff that has happened with the use of of our studio in other, I'll call it platforms. I am kind of biting my tongue here because I am recording this, but I have heard as much from some very trusted people in this space. So that caught my attention, but nonetheless, for an end user out there, a data scientist like yourself listening, no big deal. It's still open source. You can use that however many machines you like in your daily work. I've got it installed on both my work machine and my dev machine here. It's been working great, and I think the future is bright. And I dare say the timing of this probably is no coincidence that we're about a month away from Posikov, and I'm sure this was a a big feather to to shout out over there. But, yeah, Mike, exciting times. Positron's out of beta. What do you think?
[00:09:41] Mike Thomas:
Yeah. I'm very excited. And I think that whole elastic you know, the more that I'm reading up on it, that elastic license, mostly just means and I think this will be fine for pretty much everyone out there, that you can't, like, take positron and make it your own company's offering, like, turn it into some particular SaaS offering. And you're correct, Eric. I think we saw some instances of companies doing things like that, with the RStudio ID. So to me, I think it makes a lot of sense. You know, coming for soon for the the Posit workbench folks, which is exciting, exciting, you'll see Positron as a generally available IDE type. I'm imagining it was in pre preview for a little while, but for everybody out there, you'll be able to start using it, as your IDE of choice in Posit workbench if you like.
And one thing that I I did see in the article that I also liked was a sentence that said, we are committed to maintaining and updating our studio. So not just maintaining,
[00:10:41] Eric Nantz:
but also updating. That was a key find there. Yeah. It could have been easier to say maintain, keep the lights on, but they wanna keep improving it. Right.
[00:10:49] Mike Thomas:
So it's it's not like RStudio is getting deprecated. If you choose to continue using RStudio because that works best for you, then by all means, go ahead and do that. The positron assistant is very cool. It sounds like that's in preview. And the only thing I wonder there is if you can sort of bring your own LLM, like a local open weights model for privacy purposes, or if you have to use, like, a third party API. I'm assuming most of the docs point to the third party APIs. Yeah. As of now, I believe for co completion,
[00:11:21] Eric Nantz:
it's GitHub Copilot. And then for the agentic, you know, chat like interface, right now, it's Claude Anthropic. But I have heard from, you know, Joe Chang himself that they are looking at adding other providers, including bring your own model down the road.
[00:11:39] Mike Thomas:
Very cool. If, if Joe or anyone else is listening, you should check out the continue extension in Versus Code. It's it's really cool. It allows you to, you know, choose one of those providers or bring your own, local something that I'm actually giving a internal talk to our team today on how to configure that. Nice. Pretty exciting for privacy purposes, in some cases. Right? I think a lot of the times when I'm authoring code, it's not a big deal if if it's going back and forth to Claude or something like that. But if I'm asking it to reference a and use this context, like a proprietary document that, a client gave to us that has, you know, financial information or something like that on it, then I can't I can't do that. So I have would have to use a a local choice. And instead of having to, you know, spin up some sort of separate Ollama, it'd be nice to have that all sort of in that same UX.
So, just just rambling now. The continue extension allows you to do that, so maybe they can borrow some of that technology for Positron Assistant. And I think, you know, not to I think at, like, a higher level, just having everything ready to go for both R and Python is awesome. And you can't take that for granted. Like, that's not easy to do, to be able to just have in this particular IDE application just ready to go whether you wanna code up R or Python. There's for anybody that's either tried to install R or Python and and get packages and environments up and running and things like that, it's non trivial, especially if you're using the language that you're less familiar with. Right? If you're a Python user trying to start in our project or vice versa. And it may save you from also managing, like, a bunch of Versus Code extensions to have to do that.
[00:13:29] Eric Nantz:
If you're I can speak from experience trying to manage. You you recall, and others may be listening, I was an early adopter of the dev container setup and Versus Code and using the r extension a lot. And and they got me pretty far, but then when, like like you said, I had to go dive into either some Python coding or stuff, and it's like, oh my goodness. That is a lot to manage. So having, like, the batteries included, so to speak, as long as you've got R and Python available on your system, it's gonna hold your hand much easier than if you have to bring your own kind of dev setup with with Versus Code. So I do appreciate that quite a bit.
[00:14:07] Mike Thomas:
Absolutely. And I think, you know, one extension of that, no pun intended, is the database connection pane. Like, if I was to try to do that from Versus Code, I'd have to have a particular extension depending on what type of database I was connecting to. And I'm imagining in Positron, if you're using DBI or the pool package to manage your database connections, it doesn't matter if it's Postgres or a regular SQL Server or, you know, some some AWS, offering. If If you're, you know, leveraging those packages, then you should have this nice connection pane that will allow you to actually explore your database objects and and see that right in front of you, which is super cool. And then if you do wanna need to extend Positron, you can use any of those open VSX extensions, which is awesome. And and the last thing I think that's really helpful that speaks to my earlier point about having everything kind of ready to go for both r and Python is that there's, I think, ready made templates for UV and RN. And I think UV is kind of the leading virtual environment, manager for Python, and obviously RN, I think is still the big one on the R side. So I think that's possible, you know, to set up mostly through the UI instead of having to do, you know, pretty tricky, you know, command line, terminal type of stuff to get those environments up and running, which has been tricky for me in the past. And I know a lot of folks virtual environments are not fun. So anything that they can do to make that easier is awesome. So I'm very excited.
[00:15:34] Eric Nantz:
Yes. This boy, has that been a pain in my existence in years past. And one thing I've mentioned it before, but, boy, I I still have to give kudos for this. The very fact that I can just use a system wide install a positron on my setup, but yet have Nick's behind the scenes manage the R and Python installation, and it just works. Holy smokes. That is a game changer for me. It is very similar to what I felt with the dev container set up years ago. But now with Nyx, my goodness. It's the possibilities are almost endless. So I am definitely using that. And, I remember Bruno, once he shared that vignette on Rick's, oh, yeah. Positron. You just have to you have two ways of doing it. And I took the easy route, and boy, no easy route just works. So another another win for for for Positron on that sense. Because of RStudio, you have to actually install RStudio in that same Nix environment. That gets kinda tricky, especially if you're doing any WSL stuff like you have to do on Windows. So the fact that with this, that's all a thing of the past. Thanks to Positron and extensions. Yeah. That's a chef's kiss right there.
[00:16:46] Mike Thomas:
You'll be happy to know that in my slide on environment management for my Positconf talk this year, I discussed Posit workbench, dev containers, and nicks. I would never forget you.
[00:16:57] Eric Nantz:
Oh, my my heart flutters now, Mike. You know how to speak to me. Oh, I needed that this week. Well, since our esteemed, curator Colin Fay is at the helm here, it's no surprise that our next two highlights are definitely focused on the shiny space, and we're always happy to talk about that and some of the great, developments that are happening in the shiny ecosystem. And for this next highlight here, it is a new perspective and a new tool that is at our fingertips now for what can be a very difficult task of testing your Shiny app. We have covered in other highlights the the ecosystem around what Shiny has built in to help you test what you might call the server side logic of certain pieces of your app, including modules, which can get you pretty far.
And where it does not get you as far potentially is if you have a shiny server side process and say a module or elsewhere where it's not just the ReactOS from a classical set your input and, you know, the ReactOS downstream, whether it's a reactive dataset or a reactive plot or what have you, It just works to bring all that together in in the the way you do shiny testing in basic shiny itself would test that, you have a test server function that can help you along the way. What happens though if your logic also has a lot of interesting UI updates dynamically on server side via the update family of functions, or maybe you wanna update that value in the drop down, that value in the date picker and whatnot. It wasn't so trivial to accomplish that with kind of this test server framework. Well, there is a new package to address this very need, and this package is called Shiny Testers and has been authored by Ashway Baldry, who is a senior data scientist at Ascent over in The UK.
And and I'm I wanna say right off the bat, Ashway is not new to the shiny space. He has made a few, very novel contributions, and we'll have a link to his, kind of portfolio open source page in the show notes. There's a lot of great finds there that I'm gonna be looking at. In particular, he made a a module called designer It was like a an attempt at wireframing Shiny apps, which is pretty intriguing back in the day. Back to the the task at hand here, he has written Shiny testers to be kind of this one call kind of function in your test server logic that if you have any part of your server side process that does this updating of an input, which then, of course, would feed into additional reactives, you can incorporate all this with literally one function call called use Shiny Testers in the body of your test that function or test that test, I should say, that's leveraging kind of what Shiny does for the test server paradigm.
And if you have any in your UI of the app, any of these update, you know, any inputs that need updating in your test, you have, like, say, an update date input, it's just gonna magically work the way you would expect about you writing custom code. And if you want to attempt this before, that's where I also have a link to the the github repository of the package itself in particular the package documentation. In the getting started vignette in particular which we'll link to, he shows what that custom code would look like using a combination of our lang kind of like dynamic expression, you know, inserting that this package is gonna let you kinda have free of charge with just that use Shiny Tester. So in the example on the blog post here, he's got an observer, an observe event that's based on a button press that's gonna update a date input with a new value, maybe a new minimum value.
And then in the body of the test server you've got session dollar sign set inputs a way to, in essence, change the input values based on that. And then he also sets the input for the, I guess, the action button that's being pressed. And then once that happens, then he's able to simply check then at that point, does that input value equal what it should equal after that observe event? I admit I I will have to sit down with this a little bit, but I definitely do have some apps at my in my current, day job projects where I am updating observe updating via observe events certain inputs based on other choices that the user has made in the app or other downstream reactives that have happened in the processing.
So there's a lot going on under the hood here, but I think the key takeaway is you as the end user, if you wanna stick with kind of this test server paradigm of testing kind of the the behind the scenes of your shiny UI, but yet still wanna be able to dynamically update these inputs. It does sound like ShinyTesters is a way to scratch that particular need and to have a pretty elegant way of doing it. So it is still in GitHub. I believe he's playing the release of the CRAN in the near future, but certainly I am more than happy to have another, tool in the testing space in my toolbox that can be less of a footprint, so to speak, than the full blown, say, say, shiny test two suite of the whole dynamic, you know, Chrome process that's manipulating inputs. This is kinda getting you there almost all the way. So Mike is smiling here. He's got a lot to say here. Let's hear it.
[00:23:18] Mike Thomas:
No. I don't wanna talk about headless Chrome right now. I fought headless Chrome last night. Oh, okay. Five hours. Sorry for the bad bad memories there. No. No. No. It's okay. I did figure If anybody is trying to use types and Mermaid JS in a dev container, anybody sits at the intersection of those three things. I'm I'm here to help. I figured it out. No doc. You'll find a way to contact Mike in the show notes because there's a lot of you out there, I'm sure. Yes. Mermaid JS does not like, Mermaid JS in quarto does not like Docker. And they put that in the documents, in the the quarto docs. But, anyways, I digress. This sounds like, you know, as you mentioned, Eric, a way to do some Shiny testing, particularly across these update family functions without needing, you know, the the headless Chrome and and everything that goes along with that for Shiny test two. And I think that that's really powerful, potentially.
You know, one of the interesting things in the example implementation is there's kind of an entire server function stuck in the test that code. And I'm imagining that for the purposes of, like, reproducibility and as the app changes, you're not going to want that to be the case. You're going to actually want that function defined elsewhere, you know, in your R directory, and then be able to leverage it within your test that suite here, and probably still have your, shiny, you know, colon colon test server function in the second half of this this test that function. And I know this is probably difficult to articulate on a podcast, but it's it's fairly straight forward, this example implementation. If you take a look at the the blog post and sort of the first snippet of code example that's been put in there. And very, very easy to to do things like within tests that, you know, expect identical between, a particular hard coded date that you might have and the update that you're trying to push.
And, I think it's very obvious, very straightforward in its implementation. And we use, at Catchbook, the update family of functions constantly all the time, and I'm sure you do, Eric. If you are out there using a lot of render UI, you're making your app slower and clunkier than it needs to be. That's all I'll say. Eric and I could do a whole hour long podcast
[00:25:49] Eric Nantz:
about why that's the case and why you shouldn't do that. We have definitely touched on in our previous workshops too. I remember very well. Yep.
[00:25:56] Mike Thomas:
People are like, why? It's it's it's using, you know, overhead that doesn't need to be used, when this update family of functions exists. And a lot of people that I run into don't even know that that update family of functions exists, and it's it's life changing. It certainly was for me when I figured it out. So having sort of this testing format against those update functions, again, that we're using constantly, I think is is really helpful. Excited to see how this package progresses and ideally makes it to CRAN in the near future.
[00:26:27] Eric Nantz:
Yes. I'll be watching this space quite a bit, and I do have a, yeah, a couple of day time or day job, I should say, projects where, very, you know, complex shiny app that we're developing. We're We're getting into that testing phase. And no, I was not a good boy, Mike. I didn't build my test right away. I do have to bolt them on, but this gives me gives me kind of a way out of the, you know, I I hate saying it because Barish Swirk is a good friend of mine, but shiny test two is is sometimes a hammer that doesn't need to be the hammer if you can accomplish a lot of it. In a, if you're doing what we Mike and I would call the quote, unquote right way of having your business logic and fit for purpose functions that you can do and test that out alone, go for it. That's awesome. Maybe even a dedicated package, even better. But then when you do add that in between state of the app is doing something, it's probably calling a lot of functions you've built outside of, you know, Reactors or whatnot, but you still need some way to test kinda that cohesive experience with the dynamic UI updating that you're doing in the more logical and and more performant way with the update family. I think this is this is massive. So it flew under the radar, certainly. That's why we love doing our weekly. I would not have known about this probably otherwise, until maybe a random crayon, you know, message. But this is I'm gonna be playing with this probably in the coming weeks and, yeah, not a moment too soon.
And rounding out our highlights today, we've got another awesome shiny post about a feature that definitely does not get a lot of attention, and I definitely share, you know, the the same, sentiments of the author here of trying to get the word out there in many different ways. But our last highlight comes from Mauricio Pacho Vargas, and he is definitely not a stranger to the r community, and and he's been around quite a bit with many contributions actually in the c plus plus space amongst many other improvements. But he talks about Shiny in his, blog post here in the highlights about a a very neat trick that you can do to help ingest kinda new parameter values in a typical Shiny application via parameters to the URL.
Now what this might mean if you're thinking about what do you mean parameters in URL, I just go to a web page and it just works. Right? Sometimes depending on the page you go to, especially if it's more of a classically designed page, you might wanna try looking at what happens after the .com or this, you know, the the the TLD domain at the end. You might see a slash and then you might see what looks kinda like key value pairs or you might say some value or some name of a variable equals some, like, number or some really random string, and you might see a few of those separated by an ampersand.
Those are what we mean by URL parameters. And the default invocation of Shiny, you don't necessarily get that, you know, right away. You have to kind of build that in. How do you build that in you ask? And that's where the blog post comes in with one way of doing it. And, and, Pacho demonstrates this via a golem, you know, app, which again, you know, big props on that. We are all big fans of golem here as well as our curator, of course. And this is tapping into a feature that I think deserves more attention. I have more to say about that shortly of bookmarkable state, but there are different flavors of doing that. So in the flavor of this example here, we got a very simple, server app, which I think has only a a couple inputs, for the UI.
And then in order to register an app for a bookmarkable state here with the URL parameters, you first have to figure out how do you trigger this. And there are different ways of triggering, like, the act of generating these parameters or these values. In here, he's just using a simple observe block that is gonna change after every input change. And now that might be too greedy to some, but it it definitely works here in this, tutorial like example, converting the input object to a list via the reactive values to list, and then making sure he excludes an input that he doesn't care about. So you can give it the input ID of a input you don't want in this URL parameter and with the set bookmark exclude function. And then when you do that, the next call is just simply session dollar sign do bookmark. That's gonna help register these parameters.
And then the on bookmarked function, that's kind of a callback function of sorts. He is then I dynamically updating the URL that's gonna have these URL parameters baked in after that operation. And then in the UI UI of the of the app, it's very straightforward. It looks like a typical Shiny app with a sidebar layout, three select inputs, one main panel, and then a slider input. And then the key part is that you have to wrap this It's a the typical Shiny app UI function. You have to make it a function with the request parameter as its default, you know, you know, per one parameter, but then the rest of it is simply a tag list of the rest of the rest of the elements.
And with that, just some more Golan magic there behind the scenes, and then you can run the app. And then when you run it, and he has an example at the end of the post here, the URL has got kinda that local host URL, but then there's a slash question mark underscore inputs and then we start to see what the actual values are where it's maybe like for the species. It's the when the penguins say you set the idyllis, you know, species. The island, you can Bisco, I believe. But you'll notice that if the text has some kind of special character in it, in the URL parameters they have to do this fancy percent number to encode a a special character, I believe. Something like that. I'm not an expert on that side of it.
And that can get you really far. That can get you really far for these simpler apps. However, I will mention you might hit your limits on some of this, especially if your app has a lot of inputs that you want as a parameter. Because even though I have seen some really long URL strings in some of the apps I visit in the day to day, whether shiny or not, There actually is a limit to how long that address string can be, and you might find out the hard way if you use this URL parameter method for an app that has more than maybe a couple of modules of a lot of inputs inside.
So, there is another path forward, which I'll get to shortly. But first, Mike, what do you think about these, techniques here?
[00:33:49] Mike Thomas:
I think this is really helpful introduction for folks who are looking to get into bookmarking, particularly if you are using, Gollum. And, specifically, you know, there's I'll be honest. I haven't done a lot of bookmarking. I I should have, but we just haven't for whatever reason. And I think most of these bookmark, functions are sort of Shiny out of the box functions like set bookmark exclude, the session dollar sign do bookmark, and then the the on bookmark and update query string. Are those all pretty much native to to Shiny? Exactly right. Yep. So we're not using anything, you know, any crazy, additional packages. This is all sort of native technology, which is great. You know, one thing that was interesting to me as well, especially as you talk about, having query strings that are or URLs, I should say, that get really long really quickly is this function called set bookmark exclude.
So you're able to actually take the names of one of your input IDs that you have and just use that within double quotes within the set bookmark exclude, function here and ensure that that particular input widget, whatever it may be, is not used in the bookmarking function at all. So I would imagine if you sort of send this URL to somebody else who wants to access the app, you know, whatever you have that widget set to will not be sort of captured for them when they go to, you know, enter that URL in their own browser, which I think is is very helpful in situations where you have a ton of inputs but you only care about sharing the state of one particular input in your app. So that was something that I learned that I think is really useful. If you're coming from, you know, the Gollum world and you take a look at the code here that Pacha has in the blog post, I don't think it's very intimidating at all. One great catch, Eric, that I didn't catch the first time around, as you mentioned, is in the app UI code, which is a function sort of like everything in Gollum, it needs to take a parameter now called request.
So I think that's, you know, something that's easy to miss in this blog post that I think is critical to making this all work. But as you mentioned, Eric, these URLs can get real long real quick if you have multiple modules, multiple inputs, things like that. You have any, you know, additional reading material that we could brush up on on this topic?
[00:36:18] Eric Nantz:
I dare say so. I have been in this space for a bit, and I have fought these battles the hard way a lot of times. And for those that aren't aware, Shiny bookmarkable state, what we have here is one flavor of it, the URL flavor of it. There is another flavor of it that is definitely more akin to more complex applications overbuilt with golem or not, and that is called server side bookmarking. That is where instead of the URL being updated that you could copy paste and send it to your your colleague or your customer, for replicating a certain situation of the of the app UI, you actually would save the state of the app via the inputs and any reactives that you think are important enough. There's a way to do that as well. But it gets saved on the server process, which is either a local directory on your file system if you're running this in a vanilla, like, posit workbench, positatron, or r studio session on your computer.
But if you are the using this on, say, a posit connect server or a shiny server pro back in the day, these server side bookmarkable state files would be saved in some kind of cryptic area on the server that only an admin could have access to. That might be fine for or a lot of use cases. But for me, it wasn't quite because I wanted my app users to be able to access these objects that are saved with bookmarkable say, especially some of these reactives that I saved out and these input values into other situations. So it all so this is all culminated with what I will be talking about at POSITCONF, my new r package called shiny state.
I won't say I have the most creative naming, chops in the world, but nonetheless, this is a a kind of supercharged version of bookmarkable state where I'm gonna put the power of where you store these bookmarks in your hands, Mike, because with shiny state, I'm gonna let you tap into the power of the pins package and let you choose where those bookmarkable state files are sent and open the door for many possibilities that the default bookmarkable state feature doesn't quite allow for, including the ability to share perhaps a bookmarkable session with your teammate, maybe your colleague that's using the same app, and you can, in essence, collaborate on, application experience together.
It won't be quite like a Google Doc thing, but it'll be much closer than you get in the vanilla shiny bookmarkable state. So, which I got joked to many times, this is very much a conference driven development paradigm. I've got the the package on GitHub, and I'm putting my talk together for positconf, but this has been a huge this this, paradigm that I've put in shiny state has been custom code for a very long time in my one app to another kind of copy paste this stuff and you know, Hadley's in my ear at the moment saying if you're doing that three or four times, that's gotta be a function. Well, it was a function, but I kept doing that three or four times in many different apps. So it was like, make it a package in my head. So, yep, that's why shiny state exists. And I'm really excited to see others try it out. Very early days, but I think it shows great promise. And, like I said, the power is in your hands for Hayutayor Bookmarkable State. And I'm really excited to see where it goes.
[00:40:02] Mike Thomas:
No. We're extremely excited for, your talk and the the shiny state package that I know you've worked super hard on. And I think parlays with this blog post,
[00:40:10] Eric Nantz:
Bipasha really nicely depending on how complex your use case is here. So great way to round out the highlights this week. And I dare say, I'm, I've been to I've been very fortunate. I've been to every iteration of our studio in Posikov. I don't think the book marketable state feature has ever been mentioned once. That is how under the radar that has been, but those of us in the in the industry are consulting trenches. Boy oh boy, it's been a valuable thing, and I think once hopefully, the shiny state kinda takes off, then yeah you might find some interesting you know uses of this mic and you of all people I think will appreciate what what is in potential here for using this
[00:40:54] Mike Thomas:
absolutely gotta get this thing on crayon though because there's a couple other shiny states packages floating around on GitHub. Oh, really? Well Watch out. Watch out. Okay. That's good to know now. Maybe I should have known that sooner. Nonetheless, the name of it is Sorry. Most of them, don't look to have any activity in, like, the last three years. Okay. Well,
[00:41:14] Eric Nantz:
yeah. Like I said, I'm in the conference driven development mode. I do want this thing on Kranos sooner or later, so that will be another journey. But we hope that our weekly helps of your journey in data science, especially the use of R and open source in your data science journey. Every week. Tons of fantastic resources. We obviously can't get to the entire issue. We'd be here for almost five hours if we did. But nonetheless, that is for you all to catch up on after this episode. You can see all the excellent, you know, links Colin Fay has shared with us on this week's issue. And, of course, this is a community project. This isn't like some of those things you might see on, cough, cough, LinkedIn, where they're doing their own fangled newsletter of sorts about the r space. This is a community driven effort.
I I do throw a little shade there. I couldn't resist because I'm very proud of where r weekly stands in in the in the statuary community. Certainly, some talks that use r really inspired me to say that because r weekly has had a hand in some really interesting community efforts recently that I heard about. But we are also driven by your support too in keeping the project going. Best way of doing that is to share those great resources you found, blog posts, new package, maybe a new thing on GitHub you discovered that's really interesting. Our curator will be glad to contribute that into the next issue. We're just a pull request away. Everything on GitHub, everything transparent.
Absolutely love it. And also, we love hearing from you too. We are available on our, first, our podcast page that you get in the podcast player. We have a link to the contact page. Definitely send us feedback there. It's always much appreciated. If I bumble something, especially your pronunciations, boy, I need to hear about it because I'm not the greatest of speaking names. But, also, we love hearing from you about our feedback on social media. I am at [email protected] on Blue Sky. I am also on Mastodon with that our podcast at podcast in this house social, and I'm on LinkedIn. Definitely not causing any weird posts there. Just some fun things here and there. Mike, where can the listeners find you?
[00:43:28] Mike Thomas:
You can find me on blue sky as well at mike dash thomas dot b s k y dot social Or on LinkedIn, if you search Ketchbrooke Analytics, k e t c h b r o o k, you can see what I'm up to.
[00:43:40] Eric Nantz:
Very nice. And I just saw I think it was a week or so ago. Your team is expanding once again. Got some great new talent coming on your team. It's always great to see your your humble little, consulting shop grow and not so little anymore, is it? You got a lot going on there.
[00:43:56] Mike Thomas:
Thank you very much. No. Very exciting and open source all the time.
[00:44:00] Eric Nantz:
That's the way we love it. Yep. So with that, we will close-up shop here on episode 210 of our weekly highlights. There may or may not be an episode because both of us have a lot of things going on next week, but we'll see what happens. Either way, we hope to see you back here for another episode of our weekly highlights either next week or soon after.
Episode Wrapup
