Erik Rasmussen - VIDEO EDIT
===

Paige: [00:00:00] Hi, and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log. Rocket provides AI first session, replay, and analytics, which surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at Log Rocket dot.

Hey everyone. I am your host today, Paige Needing House, and today we have Eric Rasmussen, a principal product engineer at Adio, here to talk about React Beyond the dom. Welcome to the podcast, Eric.

Thank you very much. It's, it's good to be here.

Well, we're excited to talk about this with you because you, not that long ago, gave a talk about it at the City JS Conference in Athens, so let's just dive right in. You say in the talk that Reacts core platform or core library, excuse me, is platform agnostic, yet most developers only use it for web apps.

So what sort of untapped opportunities do you see for using React outside of the dom?

Erik: Right. Well, one of [00:01:00] the interesting hidden, uh, like superpowers that, uh, any React developer that knows how to build a web app, ~uh, ~actually has, is that you can use your same react, uh. F mental model to render to things that are not the dom. Like there are, um, there are several other renderers around the most, uh, famous is, uh, react native that renders not to like a web view in, in a mobile app, but to actual native components in, uh, iOS and Android, which is extremely powerful because it.

I've never learned, uh, swift or objective C or the version of Java, that to build an Android app, but as a React developer, I have built mobile apps for, for both platforms, which is just an amazing, uh, bit [00:02:00] of technical leverage. And there's quite a few others like you can render to A PDF. Again, I have no idea how A PDF is structured internally.

But I have, I have built a thing to export, uh, a nice PDF invoice or whatever, which is again, a superpower that React gives us that not a lot of people are aware of, which I think is pretty awesome.

Paige: ~Absolutely.~ So one of the things that you mentioned during the talk was the role of React reconciler, and I was hoping that you might be able to walk us through that and talk about why it's essential for building custom Renderers.

Erik: ~Right. Well,~ Well, the React reconciler is, uh, the part of React that takes the JSX that your components output and, uh, communicates that to your host platform. The host platform for React Dom is the DOM, or if you're on the server, to render out htm l as a [00:03:00] string. Or the host platform could be the mobile app or whatever, but the reconciler is, goes through and, on each render cycle, uh, determines what parts of the host, 

Document structure need to be updated. Uh, and there's a nice way to do that, that I go through and I talk about with implementing these different methods to create the host specific structures that you need.

Paige: So the react reconciler is what does the ding and decides what should still be displayed in the DOM versus what needs to be removed.

Erik: ~Uh, there's the actual, ~it does do some ding, but the actual, uh, like virtual dom ding magic, that is what made react so relatively fast with all these renders is actually part of react dom because it knows specifically about Dom, but uh, the [00:04:00] reconciler. It does do some of that, but for other platforms as well.

Paige: ~Got it. Okay. ~So when you're designing a host config for a new renderer, what are some of the key decisions that will shape how it behaves?

Erik: Well, I mean, you need to understand the structure of what you're outputting to and you need to understand how the, um. JSX components that you are supporting will be represented. And so if you're rendering to canvas or something, then you need to provide your basic, 

Structures like a wreck or a, or a line or a circle or whatever. Um, and then it's just a matter of taking those JSX components and converting them to wherever you're going.

Paige: in what scenarios do state machines make sense when working with Custom React Renderers?

Erik: ~Okay. ~

Paige: x State is really the only state machine system that I'm really aware of. Are there other options out [00:05:00] there?

Erik: I think there are, but X dates is the most full featured And best, like, they've done so much work to, with like TypeScript and, and things that, like, if there are, I think I've, I've seen some, like I've read some like read mes of some other libraries, but I've never been tempted to, to use another one. you can build your own with just like with, with you state hooks and saving. Like, it's not that hard to build a really trivial one yourself. Uh, but if you want some, a full featured one that like has side effects and talks to other actors and things, X date is the only game in town.

Paige: So how can platform agnostic rendering open up possibilities for things like IOT devices or embedded systems or even hardware interfaces?

Erik: ~Right? Well, so the,~ when I was. Deciding for my talk of like, what could I possibly demo, uh, that is a thing that you don't think [00:06:00] React has any business doing. Uh, I came up with the idea of what if I could control, uh, some iot devices, like a, like a light bulb with, uh, using React rendering. And it turns out that.

When you're, when you have full control over the reconciler, you can, after every, after every commit, you can go and look through what the, what the current state is and, or like, as you're committing, you can send off imperative messages to whatever system you want to talk to. And so, and for, for my demo, whenever.

Uh, a a a bulb prop changed from, uh, on faults to ont true. I could send a message to an iot device to turn the, turn the light bulb on and vice versa. I thought that was a pretty neat idea, and I think it makes for a pretty cool demo.

Paige: I think it does too. I mean, [00:07:00] everybody that I've ever talked to worked with and I work for now for an IOT company as a software engineer. Like the most impressive demos by far are the ones where you just flip a switch, turn a light on. People still love that.

Erik: There's something about like hitting save in A TSX file and it's hot reloading to the real world that. Like blows people's minds.

Paige: So when you are deciding, uh, what kind of a project to build, how do you decide whether to use a custom renderer versus adapting an existing one?

Erik: It depends. I don't have, like, I haven't built a lot of custom renderers. Um, there's this very specific use case at my job where it made a lot of sense to use a custom renderer, It's not like, now that I know how to build custom renderers every, you know, everything looks like a nail that I can hit with that.

I think anything that, is [00:08:00] it anything that is ui? So like if you had, I don't know, one of those, uh. Steam deck things or stream deck things that, uh, with buttons and lights and stuff. Like if you were rendering to something that has lights and buttons, like that is a ui.

If it, even if it's might be physical or, uh, or to, I don't know, like, uh, if you had control over like a digital picture frame or something like rendering to that where it's UI that needs to change either over time or through input. I think that makes a lot of sense. Uh, or anything that's inherently like tree shaped that might change over time.

Um, makes sense. But yeah, like at the, at the end of my talk, I, I gave a couple of examples that I could think of, like maybe you could use it to, I don't know, like position a drone or something. Or like do, like, there's gotta be a really interesting. Use [00:09:00] cases in the, in the real world for, or, I don't know, a laser light show or, you know, whatever.

Like you can figure as long as it's something that changes over time and that it is UI in any way, like in the way that, like a laser light show is a ui, right? Uh, um, anything like that could be done using a React vendor.

Paige: Well, speaking of UIs, how do you test and debug a render that doesn't have a traditional visual UI like a webpage?

Erik: I would write like a unit test or something that made sure that when you gave it this JSX, it either called these imperative functions in the right order or it if you were just going from JSX to some sort of JSON structure. That it gave you the correct one, and that when you changed the JSX, then the JSON structure changed.

Just [00:10:00] like typical. Uh, when I give you a, do you give me b sort of unit tests, I think is is the way to go

Paige: So what are some of the main security considerations when allowing third party code to render UI inside of your application?

Erik: Okay, so that gets to what we're actually doing with React Reconciler at aio. Um, so the company I work for is building a CRM, customer relations management tool. We are building like an actual CRM that people like to use, like it's beautiful and friendly to use. And because CRMs are, is, are famous for, uh.

Like no one, everyone hates them. Uh, but at the US building one that is really, uh, really nice and really easy to use, because we can't build out every possible use case that clients might want. Uh, it's important to [00:11:00] allow. Sort of plugins, uh, we're calling them apps to run inside of Tio.

And so we need the ability for, like, we have the basic requirement that a third party, uh, developer should be able to build something in TypeScript, give us a JavaScript bundle that we then execute somehow to draw. ui, like a form or something inside of our web app ui. And so that's a really tough thing to do securely because you can't just run third party JavaScript in your web app because it would have access to all of your cookies.

It could. Access any ap, any API that your user has, has access to, and then send that data off somewhere to some evil server. Uh, like there's, it's just a [00:12:00] really bad, uh, scenario. Uh, so what we've designed is, we take your, take your third party bundle and we. Open up and, and we, we load it into an iframe that is not on the same domain as our web app, so it doesn't have any cookies.

Um, and then in that iframe, we run our own, uh, custom JavaScript runtime that's like built in c and wasm and implement, like, implement its own little node You can think of, like no js, like a, a JavaScript runtime in the iframe. And only in there do we execute the third party code and inside that tightly secured box, it doesn't have access to fetch, it doesn't have access to window, it can't talk to documents.

There's no dom. Uh, it only has access to the APIs that we give it. So like [00:13:00] we implement, set time out and you know, set interval and those, some basic things like that. And. But then we let you give us react components that we render inside of this sandbox. Using, using React, but using our custom render. So what actually gets rendered to is A-J-S-O-N blob that we then on each render send securely out of the iframe, like out of the runtime, out of the iframe, back to the, to the web app.

And then from that JSON, we can reconstruct the. Uh, using our UI components, whatever the app developer wanted to, wanted to render. If they wanted to render three text boxes and a submit button, then that's what they would do in our custom react language. And then that would then translate into UI in our web app, uh, Which is [00:14:00] an an a really impressive use of, of React and reacts, reconciler and react vendors. And it's like, because React lets us do this, we can give the developers a really comfortable developer experience because they look at it and they're like, oh, this is React. I can use all my React hooks and all my react knowledge to do this, but then I, like, they can't output divs or spans or anything.

They can only output the ui, the pieces that we give them.

Paige: Very cool. I mean, I've never heard of anything like that before, but it sounds great and sounds like a, a wonderful developer experience.

Erik: ~Yeah, it's, it's really like when you first,~ when you build your first app with our, with our, at. SDK, it's like it very quickly. You can see your own UI inside of, inside of Tio, and then you can make a change and it, you know, hot reloads and it's, it feels very [00:15:00] natural to a modern React developer. But all the stuff that's going on under, under the scenes to make it super secure and, uh, and to do that is, uh, pretty impressive.

Paige: So earlier when we were talking, you said that React has become such a ubiquitous choice because you can do React on the Web, you can do React Native, you can do React to PDF. Do you think that React is going to remain a go-to source for this kind of cross-platform rendering, or could another library potentially take its place?

Erik: ~So~ I think all of reacts current competitors like View and Solid and whatnot, uh, also allow custom renderers. So it's not a unique thing to react, but, the theory I've heard and I, and I kind of like, is that React is kind of here forever. I, I've, I've always imagined, oh, what, what could be after React?

But I think React is here forever because it was the ubiquitous [00:16:00] framework when LLMs came online. So they, the majority of their training data is react. And that's why if you ask any LLM, Hey, build me a page with a button that does this. It's not gonna build you something with spelt. I mean, unless you specify, it's gonna default to react.

And because, because React is so ubiquitous for something like what we're building at aio, uh, where we want the max, we want the easiest, uh, to the widest range of developers to be able to, to build something. It was a no-brainer to go with React. Uh, so I kind of feel like React isn't going anywhere, uh, even though.

I don't know. I liked React a little bit better a couple years ago, but that's neither here nor there.

Paige: I think a lot of people felt similarly about React, but it's become the new jQuery. It's here forever more.

Erik: ~Yeah, I mean, and I,~ I used to think that too, but like jQuery is also, yes, it's still kind of [00:17:00] on a lots and lots of websites, but it's not the go-to for building. Web apps anymore, but I feel like React is even, has a stronger foothold than that. I, I think it's, it's what we have, so

Paige: Are there any industries that you think could, that could benefit from using React and Custom Renderers, but haven't really explored them yet?

Erik: for sure, another idea for like a custom renderer could be like 3D printing, right? You could define your, whatever, your structure in JSX, and then in the same way that you can output to A PDF, which is like printing, uh, you could totally just output that to 3D uh, a 3D printer in whatever lang in whatever file.

Type the through your printer wants, but you could also do that for other machining tools or, uh, like any sort [00:18:00] of manufacturing, I think you could probably define your designs or specs or whatever in React and yeah, use React As a middle stage between whatever software you're using to design with, like that could output some JSX and then the JSX could then be rendered to whatever output you needed.

I don't know, like you could use it to, I don't know, tele tractor, the way to drive across the field or something like, I don't know. Like I, I think it's pretty powerful for so many things. Uh, that we can't even imagine yet.

Paige: So if you could build a purely experimental React render tomorrow, what? What would you have it do?

Erik: ~Yeah, I don't know. I like,~

~I like the, I, I don't know. I'm,~ I'm curious about the idea of like. Positioning a drone or a fleet of drones, right? and the power of React is that you can like build these components and then compose them together, right? So if you had one thing that would [00:19:00] have your drones form a sphere in the sky somewhere, then you could have.

You know, your sphere component that you could reuse a couple times to draw, to do these different things. And then you could have like, it's, it's just, and there's so many different things you could do, uh, that I wish I had time to play with them all.

Paige: That's cool. I would, I would definitely watch that talk if you were able to get drones to do that with React.

Erik: Yeah, sure. I just, I'll just put 700 drones on stage and, yeah.

Paige: Hit be a crowd pleaser, that's for sure.

Erik: No kidding.

Paige: All right. Let's go into the quick round. Before we wrap things up, let's ask a quick a couple of quick rapid fire questions. So what is one rec react reconciler method that you think developers should learn more about?

Erik: there's several that you just have to know about. There's like create instance and, you know, add child. There's just, it's not that there's one secret one that no one knows about because no one knows about any of [00:20:00] them. Uh, like there's, there's the basic ones that I've went over on my talk of, Create instance and adding children and removing children, uh, that's you need to know to do stuff like this.

Paige: What is a one line description of reacts superpower in non-web environments?

Erik: ~The ability that you can, ~the way that you can use your knowledge of building react components to render to anything.

Paige: Eric, it has been great having you on the podcast. If people want to learn more about what you're doing at Adio or explore more about different React renderers and building their own, where would you direct them first?

Erik: I have a blog where eventually I post stuff about my talks, uh, at eric ra.com. Uh, at you.com is the website for the best CRM in the world. Uh, and just Googling, uh, react Render. And there's a, [00:21:00] there's a list somewhere of the, of the most. The most common ones, like one for rendering to the CLI and other things like that.

Paige: Very cool. Well, thank you again for. Joining us on Log Rocket. It has been a pleasure to have you.

Erik: Thank you very much.