Shiny Programming Practices || Joe Cheng || Posit

Transcript#

This transcript was generated automatically and may contain errors.

This is like my favorite subject. You know, I spent like 15 years of my life building UIs in the traditional event handler way. It just felt so, so hard that it was almost offensive to me, you know, like that I should need to use every single ounce of my brainpower to hold in my head this pretty small dialogue in a Windows app, you know, like it's not the most complicated thing in the world. And yet I am straining all of my, you know, brain cells to make sure that all these relationships are correct.

It seems like everything you add makes it exponentially more complicated. That's exactly right. All non-trivial software. This is the number one problem. How do we manage the complexity? Because everything we add has the potential to interact with everything else.

Reasoning locally about the reactive graph

So what I want to say about this reactive graph issue, where you start out with an input and an output, right? Not even a reactive in the middle, just input, output, multiple inputs to one output, multiple outputs to one input. Like all of that is pretty understandable. And then you add one or two reactive calculations in the middle, but it doesn't take much for that to start becoming very crazily looking, especially when you have multiple levels of reactive calculations.

I think like a most important thing to understand is that you're not supposed to understand the whole graph. The goal is not to create a graph that you look at and say, oh, that's definitely right. Think of this as the same exact thing with functions in a normal piece of software, a normal package, which functions call which other functions. And you could draw a graph with that, right? You can draw a function called graph. And people do. There's software that does that for you, helps you make those connections. The goal is never to be able to look at that entire graph of functions pointing at each other and be like, oh, yep, it's right.

That's not the point. If your software is well-written, the point is to be able to look at any one node, any one node in that graph and prove to yourself that that node is correct. To look at one output and just look at the things that are calling into that output. Just one level, right? Like don't go beyond the arrows that are going directly into that output and say, are those correct? And if the answer is yes, then you can move on. You can move on to look at each of the other nodes in the graph.

So the point is not to be able to reason globally. The point is to be able to reason locally. This is exactly the same thing that we say about functions, right? When you write a function, the goal is not to be able to take the entire rest of your code base that might indirectly or directly call or be called by a function that's under a question. The goal is to be able to look at this function and to be able to confidently say, if the functions that this calls are written correctly, then this logic is correct.

The goal is to be able to look at this function and to be able to confidently say, if the functions that this calls are written correctly, then this logic is correct.

So you need to be able to look at this function and reason about just this function in isolation. Now you might be wrong. Like you might be assuming that those other functions are written correctly and that might not be true. But that problem is a much better problem to have to tackle than the possibility that all those functions are correctly written and you still don't know if your code is correct. Because not only do you have to know that they're correct, but you have to know about really subtle interactions that those functions have with each other.

With reactivity, this is a way that that same quality of I can look at a small piece of code and just by knowing that the reactives that are being called, if those just assume that those are going to execute at the right time, then this is going to execute at the right time. If there's something that I'm calling and I don't want to update when it updates, then I need to know to call isolate around that. So not calling isolate when I don't want a reactive relationship, that would be a bug in this code, right?

But if I don't have that bug, if I, my relationship with my immediate things that I depend on is correct, then I'm satisfied that this piece of code is correct. And now I can go look at another piece of code and make sure that it's correct. The bottom line being, if you have an app that's written out of 10 such pieces of code, then you have to make sure that 10 pieces of code are correct. And if you add an 11 piece of code, you have to make sure that 11 piece of code is correct. As opposed to having to make sure that each piece of code and all of the possible interactions it could ever have with any of the rest of the pieces.

Like now that's not 10 things you need to check. It's like 10 factorial or something like that, right? Or I don't know what the map is, but it is something that's certainly non-linear in terms of each additional thing you add, you now have to check all these, all the possible things that it could interact with. Oh my gosh, I'm going to add a new thing and it's going to be so complicated to know whether this is going to blow up something that, you know, I already have. That was the world that we lived in before reactivity, when it came to writing interactive UIs.

Modules and the puzzle piece analogy

This might go nowhere, but I think when people think about the Lego analogy, which like that comes up a lot when you talk about components in software, right? Like a lot of people think of them as like Legos. At a high level, you tend to think, oh, I want the ability to snap anything. Anything should be able to snap to anything else, right? I just want to take two software components and snap them together.

I don't get that much pushback on reactivity, like, oh, why didn't you do reactivity this way? It's not been that much of it. I think because it's sufficiently complicated that it's like, it's not the most natural thing to bike shed on, but modules are like the opposite. Like everybody's got an opinion on modules and I mean, for most of the Life of Shiny , people have had opinions on why I didn't do it the right way, you know, and the right way meaning something so different to every person.

One really common refrain was basically, people don't like that you have to pass in, like if you have something like a module that takes some kind of input that needs to be provided from somewhere else in the app, right? Like you've got a module that does something with a data frame, but it doesn't itself want to have any opinion about what that data frame is or where it came from or how it's specified, right? It doesn't specialize just on some output or whatever. How do you communicate with that module? How do you tell it, this is the data frame you should use and here's when it changes.

And the way that works in Shiny modules is when you define the module, you take that data frame as an input. You take a reactive calculation as an input. A lot of people push back on that and they're like, I don't want to have all these things that I'm passing into, you know, this Lego brick, right? Like why can't all Lego bricks just look the same, right? I don't want to pass in these four arguments that it needs. I just want to give it a dictionary. How about that? Every module just takes a dictionary and then you just have to put the right things in the dictionary and then like, look how clean the code is for snapping together all these Legos.

I just make a dictionary, put some stuff in it and then everybody gets the dictionary and oh, I can use the dictionary for both input and output. Not only can I get data frames out of it or other, you know, reactive things, I can also push values into it and then other modules can consume it. And look how easy it is to snap these Legos together, right?

This is where it's like, it's not enough that the Legos go together. They have to go together correctly, right? So Lego minifigs have heads and torsos and legs, right? You can't put a head on the legs directly. Like they have to, they only connect one way and those connections are obvious. With a lot of components, it's actually more like that. You don't want Legos that will snap together whether they belong together or not. You actually want it to be very obvious that this thing needs to connect with something that's like this. It's more like puzzle pieces.

So people arguing for, oh, let me just have a dictionary that I pass in. What they're really saying is like, oh, it's so annoying putting together this puzzle with all the pieces are all jagged. Wouldn't it be easier if they were all just squares? Like let me make this, you know, put together this 500 piece puzzle, but it'll be so much easier if they're all just squares, you know?

It is actually, you're actually making it so much harder, right? Because that problem still exists. Like you still need to make sure that that data frame that you need is provided to you. It's just now provided in a very hidden way that you'd have to go seek out that's not obvious. So you've removed the signal of how these things connect. You've removed these sort of weirdly shaped borders and replace them with flat borders, even though they can really still only connect in one way, if that makes sense.

So you've removed the signal of how these things connect. You've removed these sort of weirdly shaped borders and replace them with flat borders, even though they can really still only connect in one way, if that makes sense.

So again, just another example of that principle of small pieces that we can locally reason about and then combine them in reliable ways. And when we have just like these dictionaries that we pass around, it's removing that part of like, we need to be able to combine these reliably.