Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project or I just got off a call with a client or something like that, a lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little. Or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so I was looking around to try and find something that would work out for me and I found these Factor meals. Now Factor is great because A, they're healthy. They actually had a keto line that I could get for my stuff and that made a major difference for me because all I had to do was pick it up, put it in the microwave for a couple of minutes and it was done. They're fresh and never frozen. They do send it to you in a cold pack. It's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And, uh, you know, you can get lunch, you can get dinner. Uh, they have options that are high calorie, low calorie, um, protein plus meals with 30 grams or more of protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato, bacon and egg, breakfast skillet. You know, obviously if I'm eating keto, I don't do all of that stuff. They have smoothies, they have shakes, they have juices. Anyway, they've got all kinds of stuff and it is all healthy and like I said, it's never frozen. So anyway, I ate them, I loved them, tasted great. And like I said, you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals. Head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project,or I just got off a call with a client or something like that. A lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little, or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so, um, I was looking around to try and find something that would work out for me and I found these factor meals. Now factor is great because a, they're healthy. They actually had a keto, uh, line that I could get for my stuff. And that made a major difference for me because all I had to do is pick it up, put it in the microwave for a couple of minutes and it was done. Um, they're fresh and never frozen. They do send it to you in a cold pack, it's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And you can get lunch, you can get dinner. They have options that are high calorie, low calorie, protein plus meals with 30 grams or more protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato bacon and egg, breakfast skillet, you know obviously if I'm eating keto I don't do all of that stuff. They have smoothies, they have shakes, they have juices, anyway they've got all kinds of stuff and it is all healthy and like I said it's never frozen. So anyway I ate them, I loved them, tasted great and like I said you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals, head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

 

Hey folks, before we get started, I just want to let you know about my upcoming book, the Max Coders Guide to Finding Your Dream Developer Job. If you're looking for a job or you think you might be looking for a job in the future and you're trying to up your mobility and meet new people and things like that, this book walks you through the whole process. Go ahead and check it out. It comes out on November 20th. It'll be on Amazon and you can find it as the Max Coders Guide to Finding Your Dream Developer Job. 

 

JC_HIATT: Hello, welcome to JavaScript Jabber. This is JC Hyatt. Looks like I am flying solo today in terms of panelists, and I'm going to be joined by Dean Radcliffe. Want to say hello? 

DEAN_RADCLIFFE: Hello everybody. 

JC_HIATT: And where are you from? 

DEAN_RADCLIFFE: I'm from Chicago, Illinois. I'm a web developer out here and it's a beautiful day. 

JC_HIATT: Awesome. 

 

This episode is sponsored by Hasura.io. Hasura is an open source GraphQL engine that helps you instantly set up a scalable and real-time GraphQL backend.Hasura makes your team super productive by dynamically composing a schema backed by databases and microservices that you can securely query from front-end clients. You can check it out at hasura.io to try it out in 30 seconds. Now, a few things that I really like about Hasura, one is that it runs on PostgreSQL, which is really easy for me to get set up. It has a core authorization engine that makes the data access secure and doesn't compromise performance. It can also join together GraphQL services, so if you have microservices or SAS APIs like OneGraph, you can pull them in as well. And finally, they've been working on making it super easy for developers to write custom business logic and REST APIs and have Hasura expose them as GraphQL mutations. So go check it out, hasura.io, they're doing really great stuff. 

 

JC_HIATT: We're going to be discussing Storybook today, which is really interesting to me. I've used it a little bit, so I'm really excited about our chat. 

DEAN_RADCLIFFE: Cool. The last chat I had over on the Roundup episode, number 83, I think, not that I'm keeping track, right, was about this very topic and Charles had a lot of interest in reactive reactivity in general, which storybook is a, you know, hot reloading environment, but there's a lot of a tangents that we could take into the realm of reactivity and RXJS if you want as well. 

JC_HIATT: Definitely. Yeah. Why don't we actually start there? Because I feel like there's a lot of, I don't know. I'm not sure if ambiguity is the right word, but reactivity is kind of one of those buzzwords that I think everyone kind of has a slightly different meaning. And so let's get into just what is reactive JavaScript? 

DEAN_RADCLIFFE: All right. So reactive JavaScript, reactive programming in general is kind of the opposite of imperative. Don't tell me what to do. Suppose I'm overseeing someone doing a task for me. What I would like to be able to do is react to their completion of the task. So at a very fundamental level and from a coding standpoint, let me give you a callback and you call that with the value when you have a value, don't make me poll you, etc. That kind of scenario is reactive. Now in JavaScript, reactivity existed long before React. Basically, my first run in with reactive JavaScript, I was writing an add-in for Microsoft Excel. And you'll see spreadsheets cited in most talks about reactivity because, well, what happens when you have a sum over a range in a spreadsheet and you change some values in that range? What do you expect happens? It reacts, you expect the spreadsheet is reactive to its values. So you can think about spreadsheets as an example. And so I was, I was building an add-in for a spreadsheet and this particular add-in had to make Ajax calls and get data and populate them and do a lot of async. Oh, by the way, I'm a C Sharp developer, but in order to get the coolest UI possible with the web skills that I and the team had at the time, there was basically an instance of a web browser was the add-in for the C Sharp app. So we were writing mostly JavaScript, just C Sharp at the edges. And so we know we needed to pick a JavaScript framework and this was back in 2011. And so react was not a thing. Angular may have been a thing. I'm not sure, but anyway, what I found was the knockout JS framework was literally the first reactive JavaScript framework. Did you ever encounter that, JC? 

JC_HIATT: That was before my time. I was still just writing jQuery at that time. 

DEAN_RADCLIFFE: So, yeah, yeah. 

JC_HIATT: Tell me a little bit about it because I've heard of it, but I don't know anything about it.

DEAN_RADCLIFFE: I guess like modern things that resemble knockout the most include a mob X, the reactive state management library. And it essentially, you know, allows you to have like a spreadsheet can have a computed sum over a bunch of other properties. You know, imagine you have, let's go to the typical to do list example. Let's say that there's a piece of derived state that is the number of to do list items completed. You want to be able to specify that as a function and have that function reactively run to update the to-do count whenever to-dos become completed. So Knockout JS facilitated you writing code in that style. They called them computed properties. I think MobX calls them computed as well. The view framework also is big on computed and reactive properties. 

JC_HIATT: Okay. Gotcha. And was Knockout a, did it follow any particular pattern like in BC or was it something different? 

DEAN_RADCLIFFE: It was something different, really. You know, it was more like a spreadsheet. It had source, sources of reactivity, and then it had functions that reacted. And that was basically it. So those functions could update the DOM. They could, you know, do whatever. They could put async calls on the wire, AJAX requests and such. Yeah, so it wasn't exactly MVC. It was really more like change exactly when needed as opposed to change when told to by another object. 

JC_HIATT: Okay, for the view layer, did you use some sort of templating language or was this just kind of patched on top of whatever HTML you had? 

DEAN_RADCLIFFE: It was patched on top of the HTML you had. It was similar to Angular or Vue in that regard. 

JC_HIATT: Okay. 

DEAN_RADCLIFFE: There were some additional tags that you put in there. Yeah. 

JC_HIATT: Cool.

DEAN_RADCLIFFE: That was like reactive JavaScript programming. And that was like, I think right around 2011, there were several JavaScript renaissance where a whole bunch of new stuff came out, but each time it made me want to do JavaScript more. And, uh, I started getting into node and node I found very challenging to do. Even having done several async things in the front end, but it was just a very different way of thinking. And then by, by happenstance, I discovered a framework called Meteor.js. And you've heard of Meteor, huh? 

JC_HIATT: Yep. I think my friend Scott Tolinski is very big on Meteor. 

DEAN_RADCLIFFE: Ah, yes. He's a rare bird. It hasn't gotten like the most renowned in the community. But to quickly tie it to Storybook, one of the main Storybook contributors, Michael Shulman, I met in the Meteor community. He was doing Meteor before Storybook. So there's actually a connection between Meteor and Storybook. And one of the things about Meteor is that this idea of full stack reactivity, it just took it to the nth degree. So let me explain two task management tools and how they differ. There's Trello, whereas you move cards from swim lane to swim lane, everyone on that Trello board sees that stuff right away. And then there's Jira, where if you have 11 tabs open and you update, data in one tab, probably 10 of your tabs are stale now. And maybe they've given you a link that says, board is stale, refresh, if they were generous. So reactivity is a thing that's needed. And certain tools do use it. Trello uses it. Google Drive wouldn't be what it is without full-stack reactivity. And Meteor.js just made it stupid, simple. 

JC_HIATT: So, did it provide you with features for polling and stuff like that? 

DEAN_RADCLIFFE: Well, so, polling is an imperative way of thinking. Behind the scenes, it may use polling in a fallback scenario, but the thing was you didn't actually have to care. You could literally bind a portion of your UI to a client-side collection, basically a Mongo collection. And as you subscribe to the server, imagine the server had a leaderboard of a game. Okay. So scores are constantly changing. Leaders are moving up and down, but basically you had a one, a single binding of this piece of UI is to reflect the leaderboard and that's all you say. And as that leaderboard changes, everything up the stack reacts as fast as possible. 

JC_HIATT: So why is this not more widely used? 

DEAN_RADCLIFFE: Why? Indeed. Why is it not more widely used? I don't know. I want to continue talking to people about this where if you drank the Kool-Aid like I did, you now look at every instance of a web application that's not reactive and you facepalm all day. So how is this today? 

JC_HIATT: Would this be sort of like some sort of syntactic sugar for like GraphQL subscriptions or is it? 

DEAN_RADCLIFFE: No. There's a connection too to GraphQL, so that a lot of the folks who are working on Meteor, they pivoted. So the Apollo GraphQL team, that Apollo client library, most of those, well, the original developers anyway, they were from the Meteor community too. So they definitely baked this subscriptions notion into GraphQL. And so yes, GraphQL is one modern way that you can get a fully reactive data layer. Yeah.

JC_HIATT: these days might be a little more in the same category as Apollo. 

DEAN_RADCLIFFE: Meteor requires more buy-in to different parts of the stack. Whereas GraphQL is more agnostic to your database. It's easier to get management buy-in for GraphQL because it is less opinionated and less tied to different parts of the stack. 

JC_HIATT: So Meteor is going to be a lot more than just the data layer. 

DEAN_RADCLIFFE: Right. Meteor is not a thing you put on your Postgres database. It's primarily Mongo. It served the needs really, really well. I saw this, JC, because I ran the Chicago Meteor Meetup Group for a year. And I saw people coming in there who were designers, kind of front-end skilled. And they were just like, give me the rest of the stack now so I can start making awesome stuff. And that sounds audacious in this era of, you know, babble and build tools and everything being so complicated, but Meteor was really a turnkey solution to the point where I saw amazing full-stack apps, think about what an Uber driver has in their car to find out about people calling them and how to get there and think about what the caller of an Uber, the client of Uber services is looking at as the car is arriving. I knew people who had under two years of JavaScript experience who built that in a few months. 

JC_HIATT: I do remember the first I actually ever heard of Meteor was, um, I actually used to run a product agency and my, uh, creative director was also a front-end developer and to date had been just mostly jQuery and then he started raving about Meteor and how he needed to try it out. He was a designer at heart. So it kind of echoes what you said you were hearing.

DEAN_RADCLIFFE: Yeah, exactly. Exactly. But yeah, but these days, I think people will look for more focused tools that solve a particular part of the problem versus like an all-in-one solution like like Meteor, which is still good for what it does. But I've had a hard time talking people into like, let's do the whole thing in Meteor. But so that's kind of what led me to look for tools that can give me that reactive, both a development time experience that is as reactive as possible. And potentially if necessary and if required in production, then get me some of those reactivity tools in production if needed. 

JC_HIATT: Cool. I guess that can be a nice segue into Storybook because that's at least a piece of the stack that we can now have some sort of reactivity around, and especially for designers, right? 

DEAN_RADCLIFFE: Right, right. Yeah, so I made a little list of some problems that Storybook solves and I think the first one many people have already solved for themselves in one way or another which is when you're developing front-end components, it's nice to have a hot reloading environment, right? So save the file on disk don't even need to do a command R in the browser It just you see what it looks like at all times. So to me that's table stakes for play in this game. There's a whole lot of carpal tunnel that you can get if you need to keep mashing the refresh key. And if something does that for you, that's really nice. So that's just, you know, solution zero. Okay. It's not a comparative advantage, but then think about this. I included a little screenshot of what happened one day when I was developing a, the front end of a Rails application and I was on the train and I went to start up Rails S Rails server. And you know, this application had just grown to take on a dependency to Redis. And my local Redis wasn't running. And so I got a stack trace, couldn't start up my server, couldn't do my local development because all the backend and all of the downstream services that it requires wasn't available. So there's where storybook says, okay, fine. Maybe you have hot reloading inside of a rail server, but let's give you a hot reloading environment that requires no backend whatsoever. So very friendly for your commute your airplane time and maybe just spinning up fewer containers or processes, you can do front-end development without needing the whole back-end stack running. Kind of encourages good design practices too when for your components that it kind of ensures that anything you develop for the front end has a life of its own where its very existence is not coupled to some piece of infrastructure running or not good architecture if you can have that. So if you use Storybook, you're kind of guaranteed to have that level of separation. Does that point resonate with you at all? 

JC_HIATT: Oh yeah, yeah, definitely. I remember distinctly the first time that I rolled Storybook at one of my former jobs, we would sometimes have issues of something in one of the Docker containers not working for the API or someone pushed push something and it broke, you know, I didn't know that we were supposed to be doing migrations or whatever it might be. And something's wrong with the back end. And I spun my wheels for a little bit, couldn't figure it out. I have to ping somebody, wait on them. And while they're while I'm waiting, well, at least I can go over here and I can work on components and storybook. 

DEAN_RADCLIFFE: Mm hmm. Yeah. So it's it's been delightful to have that. 

JC_HIATT: Definitely. 

DEAN_RADCLIFFE: And then there's kind of like what you'll see, you know, on the storybook homepage, which new friend of mine, David Kershid, had summarized with a tweet where a designer presents a beautiful high fidelity mockup of the application you're building. And you're the developer and you receive that and you kind of realize that there's a thousand and two hundred eight possible combinations of states that mockup really needs to represent. And you you delicately bring that up to the to the designer and they say, well, great, I'll start working on screen number two then. There's just this combinatorial explosion of UI states. And while every single one doesn't necessarily need a hyperlink that allows you to jump to that state, maybe some of them collapse, but other times you really want to show a component, say it's a date picker, in the various states that it has. It has, you know, one date selected. It has two dates selected. It has no dates selected, et cetera. Those states storybook really it's, it's main value proposition, I think, is that it allows you to really create a catalog of your UI states. 

JC_HIATT: Yeah. And I know it, and even for the longest time, and maybe even today, the Airbnb storybook was like this poster shot of an example and Airbnb. You might even be thinking of that because I know that their calendar widget or their date picker, I think had over 1200 possible states. 

DEAN_RADCLIFFE: Oh, that very well could be what that's a reference to. 

JC_HIATT: I'm pretty sure that they might actually be talking about that in this sweet screenshot that you're showing me. 

DEAN_RADCLIFFE: Yeah. I mean, I'm still looking for solutions to this problem of state explosion. It comes up when you're unit testing as well, right? So at least with Storybook, there's a way to jump directly to a state and see it and tweak it. And that really allows feedback loop that I think, you know, reactivity is all about giving feedback as soon as possible, right? The sum of several values updates as soon as possible. So and all that is really so that, you know, feedback can be as tight a loop as possible. And so. What I found by working with my designers by I take their designs, I figure out the states, figure out the props and put them in storybook. And now there's a sharing that occurs back to the designer where they can interact with the live components. They can actually futz with them and manipulate them. And the whole goal of that is to get the feedback from the designer so that, you know, they're not filing a bug later when things are QA'd or released and they are now only now seeing that looks really bad when a product in your database has a very, very long name. I mean, that's like one of those examples that Storybook will help you catch. 

JC_HIATT: Yeah, and I think that designers and QA teams, this is a great tool for them. Do you think that we might start to see more tools layer on top of Storybook to where maybe designers or QA teams can start to compose some of these components together to make these like experimental screens or prototypes just to kind of see how these components fit together? 

DEAN_RADCLIFFE: I think in that department potentially is a tool called Framer. 

JC_HIATT: Oh yeah. I think I've heard of that actually. 

DEAN_RADCLIFFE: I know it lets designers particularly use React components in, you know, combinations like you're talking about. Yeah. We don't have much experience with that, but I know it's out there. 

JC_HIATT: Yeah. I know this is just opening up so much more opportunity for collaboration between the engineers and the designers. And I think anything that does that is wonderful. 

DEAN_RADCLIFFE: So yeah, it's, it's basically it's increased the fun because I think that it's fun to get feedback because it turns it from a, you know, you're the end of the line process to a way to suggest improvements up. Um, and it's also fun because for all the goodness that unit tests can bring to the reliability of your code and helping you design your code. They're not quick to write, nor all that fun. Some people may differ with me on the fun part. I respect that as well. I think a lot of the fun of development is watching things take shape before your eyes. And so Storybook gives you that level of fun. What really helps the workflow is that for each story. You, I'll talk about Storybook as it pertains to React, because it's available for every major front-end framework these days, which is pretty exciting. But in terms of React, the fields, the data that actually drives your component into a given state are called the props. And so in order to display your component in a given state, you need to choose and decide, at least, you know, code the props of a component. Now, when you write unit tests, you do the same thing. You have to set your component up into a certain state. So I find that if I'm gonna be writing those props anyway for unit tests, I might as well use them to drive a storybook, interact with it. I'm not a hardcore test first person, but I am hardcore that tests get written eventually. And so storybook is like, I'm designing those props, those fixtures that are going to set up the components and I'm clicking around and by the time I'm going to write the unit test, I already know how the component behaves. So I'm not going to end up wasting a lot of time discovering things through the, I think relatively slower feedback cycle of unit tests. I get a faster feedback cycle with Storybook now that I'm up to speed with it. 

JC_HIATT: I think the plugin is called knobs that you can add to tinker with the props, right?

 

This episode is sponsored by Sentry.io. Recently, I came across a great tool for tracking and monitoring problems in my apps. Then I asked them if they wanted to sponsor the show and allow me to share my experience with you. Sentry provides a terrific interface for keeping track of what's going on with my app. It also tracks releases so I can tell if what I deployed makes things better or worse. They give you full stack traces and as much information as possible about the situation when the error occurred to help you track down the errors. Plus, one thing I love, you can customize the context provided by Sentry. So if you're looking for specific information about the request, you can provide it. It automatically scrubs passwords and secure information, and you can customize the scrubbing as well. Finally, it has a user feedback system built in that you can use to get information from your users. Oh, and I also love that they support open source to the point where they actually open source Sentry. If you want to self-host it, use the code devchat at sentry.io to get two months free on Sentry small plan. That's code devchat at sentry.io.

 

JC_HIATT: Have you seen any, or maybe even used something like Faker or something like that to kind of just automatically inject random values for these props so you can kind of catch things like where you might have a, you know, text that's too long? 

DEAN_RADCLIFFE: No, but that is brilliant. It goes in the realm of like generative testing too, where you're going to be throwing stuff at your components that you didn't actually explicitly choose just to see what happens. I think I totally think there's a place for that. 

JC_HIATT: Okay, yeah. I was just kind of curious if that's something that you've already done. I'm very interested in the chaos engineering aspect of front end right now. And anything that can either on an automated basis or semi-automated basis that can kind of attempt to break components, I'm very interested in that. 

DEAN_RADCLIFFE: Right, right. Well, what are some of the causes of breakage that you think that chaos engineering could help you solve? I wonder if I have some of those same problems.

JC_HIATT: Um, well, the classic front-end issues are usually network related, right? But there's other things like maybe styles not being applied properly, depending on your platform or your browser or internationalization type issues where maybe you translate a certain word into say German, um, words are very different or the sentences are even, you know, you can have something that's 40 characters long that means 10 English words, but it's all one word with no white space and stuff. And that kind of, like seeing how components react to, to those types of issues, I think would be really fun to have done on an automated basis, you know. 

DEAN_RADCLIFFE: Yeah. No, I like that. You basically don't want, you don't want your users in production to see things that you haven't yourself seen. So you want to come up with, uh, you know, workflows and processes that allow you to see more of this stuff kind of automatically. I like it. 

JC_HIATT: Yeah. 

DEAN_RADCLIFFE: In the realm of network issues, I've got some things that I think can help with that. There's a kind of a, here I'm going to get a little nerdy, but you know, I'm, I'm sure that's just good for the show, right? 

JC_HIATT: Yeah, absolutely. 

DEAN_RADCLIFFE: So basically, I'm going to bring up RxJS. There's an image in the sheet that I've shared with you. When you talk about network things that take some time, the library RxJS is all about streams and they have another word for them observables and you may also know them as event emitters. They are things that you can react to. So they're kind of the bread and butter of reactive programming. And basically they have some things in RXJS called operators. I'm gonna talk about the concepts that those operators embody because there's this image that I have in this document that shows, one problem that is commonly needs to be solved on the front end is what happens if let's say you're making Ajax calls one after another and they start to overlap. Right. So do we need a concrete example of this or can, can you think of one? 

JC_HIATT: Are we saying the data is dependent on each other or? 

DEAN_RADCLIFFE: Oh, well, okay. So there's several scenarios, right? So in some cases there's, there's a page full of Twitter posts and you can click the like button and those likes are independent of each other. Okay. So it really doesn't matter too much if those likes overlap in time. If one like is being sent, then another one has started. You know, you could be, you could be okay with that. Now that's fine for that particular case, but there's another case that a commonly mentioned case is that of an auto complete field where if you have typed a and some results are coming back for a, and one of them is aardvark solutions. And then your next type of the character B, what do you want to do to that original request for all of the A results? Well, if you're resource-conscious, you want to cancel it. Now, some people get a little freaked out when I say cancel it, because if you've had people talking about canceling promises, you know that that is not a solved problem or a thing that everybody does the same way. There's talk of an abort controller coming out, but frankly, promises were never meant to be cancelable. And even recently, a TC39 proposable for adding cancelability to promises failed. So if you take this RXJS thing, which has been around for 10 years now, actually, far longer than promises, it was built with cancelability from the beginning. So what you can do with that is if you have a scenario where it's better to cut off the previous async operation and just simply keep replacing with a new one. Well, RXJS and by extension, this RX helper wrapper that I've built on top of it, allows you to just basically declaratively say, and by the way, these should be handled with the mode cutoff, which cuts off anyone that's in flight and puts a new one. The default behavior where the like buttons just as many of them proceed at a time as possible, that's just called parallel because effectively those Ajaxes are running in parallel. And if say you want to force all those likes to take place over a single HTTP connection because your client only has so many allowed ones back to the server and you want to reserve some of the others for web sockets or analytics, so you just want to serialize all of those. Well, that's called serial, and you can just apply serial declaratively. And then it turns out there's actually quite a few other combinations, but the fourth one in the set that kind of all goes together is called mute, which I talk about that when I see people at an elevator and they've pushed the elevator call button once, and then while they're waiting for that elevator, they push the button again and again and again, well, you don't really want to initiate anything while there's one in flight either. So what I think this does is kind of, I would call this an algebra, which is the nerdy term for like kind of a set that plays nice together. And if you can easily and declaratively just switch between any one of these modes, you're bound to find the right one for your cases in short time, or you may have a use case that's outside of these four which is fine, then you could go into kind of imperative logic and manually controlling timeouts, but all of these behaviors that come up all the time, usually one of your solutions for a given async problem is parallel serial cutoff or mute. 

JC_HIATT: So if I have, say a bunch of requests that I need to fire and to quench a order, is serial going to be the best bet there? 

DEAN_RADCLIFFE: Serial. for ordering, for preserving the order. Yep. 

JC_HIATT: So if I say, uh, you know, Twitter's thread feature where I can just add another tweet, add another tweet. I want to make sure the previous one is posted since the next one relates to that one in terms of the order is. So I would use serial to send those tweets, I guess. 

DEAN_RADCLIFFE: Bingo. 

JC_HIATT: Gotcha. 

DEAN_RADCLIFFE: Cool. 

JC_HIATT: I actually haven't still haven't used RxJS. I've only recently started to wrap my head around it, but I still haven't actually tried it out on any projects yet.

DEAN_RADCLIFFE: Sure, sure. It is a hard thing to wrap one's head around. I had heard of it around the same time as I heard of knockout. Knockout was less friction to, uh, to get started, but our RXJS it's, it's big. It's actually frighteningly big. Um, the number of downloads per month actually eclipses react eclipses. A lot of things that you've heard of, you know, if you ask like a hundred devs that that listen to the show if they've used RXJS, not many probably would answer that they have, but the download charts, well, unless they're Angular developers, in which case they definitely know about it. But the download charts, because it's bundled with Angular, because it's a part of, I'm not positive whether it's a part of GraphQL, but an observable implementation is a part of GraphQL. That's how they get that subscription logic. So, RxJS is an enabling tool for just about anything that has this reactivity feel that feels reactive. It's like it's the tool that enables the other tools you've heard of. 

JC_HIATT: Yeah, I had no idea it had been around for so long. 

DEAN_RADCLIFFE: Yeah, it's been around for a long time and it's implemented in over a dozen languages. You can literally take this object model that they have of observables and subscriptions and observers. And that object model and its behavior is implemented in Ruby, in Groovy, in Python. They're not the most popular in those implementations, but kind of as a proof of concept. What it shows is that the things defined for RxJS are kind of independent of the threading model. So if they work just as well in C sharp, where you have threads in Java, where you have threads and in JavaScript, where you don't have threads, then that's to me kind of proof that they are an abstraction that sits above those low level details of threading and yet are still capable of doing all those things that you could with like a thread oriented language. 

JC_HIATT: So tying back to Storybook, how do we tie RxJS back to Storybook? 

DEAN_RADCLIFFE: Okay, well, I don't believe Storybook is implemented with RxJS, although it is a kind of reactive environment. One of the things that I think is really useful to do in Storybook is to see states of your application like a very slow loading autocomplete that you would never see on your fast local host development machine. So I made a plugin. It's not quite knobs, but I think it's very complementary to knobs. It's called Storybook Animate that plugs into Storybook and lets you simply wrap your in another component, a higher order component, that will use an observable, that's an event emitter, a stream, to drive the props to your component. So what does all that mean? Well, let's say that you make a thermometer component. That's the example for Storybook Animate. When a user actually uses this thermometer, well, on screen anyway, they're gonna see the temperature rising over time. And it actually rises in a kind of particular way as it gets close to 100, it slows down. I think that by using an RXJS observable to drive and animate the props of a component inside a storybook, you can really get more empathy. You and your designers can get more empathy for what a user sees because the user doesn't see the individual states that you design in storybook so much as they see series of states over time. So why not be able to just simulate that entire interaction right in storybook or to get to the point of like slow loading things a slow loading auto-complete if you can you know hard code just make a kind of stub implementation of Autocomplete that takes five seconds to load then you can click on a story that says slow loading search and when your designer says how does this look when it loads slow? Well, there you go. You've got a story that they can click on and then they see the spinner long enough for them to maybe have an opinion about the placement of that spinner and how it should look. But if you never gave them a story with some kind of built-in async behavior of your choosing, you know, they would never have seen that long enough to form an opinion about it. 

JC_HIATT: Yeah, the best I could ever do before was have a loading state story and have loading on by default and then put a knob on to turn it off. 

DEAN_RADCLIFFE: Oh, right. 

JC_HIATT: They couldn't actually see it happen in real time and resolve itself. 

DEAN_RADCLIFFE: Right, right. Yeah. And that's still more than they would have had without that. But given that I've just been working with these observables and animating values over time, you know, taking for granted a reactive environment, I was like, hey, let's just animate it right there under their noses. 

JC_HIATT: Yeah. Yeah, that's really cool, man. So I guess for Storybook itself, like are there any, any things that listeners should be aware of that are maybe coming down the pipe or if someone hasn't used Storybook before, what's like one, one big takeaway that you would like them to walk away with? 

DEAN_RADCLIFFE: Well, I would say that Storybook is a, is an actively updated project. The 5.2 release that just came out is very good and it has a story definition format that makes it even easier to define the stories. I would say go to storybook.js.org, find the front-end framework that you're using. Sorry in advance if it's Backbone. That's the one that they don't have, but pretty much anything else they have. Take a look at the starting instructions for your framework and write your first story. You can do this in under 15 minutes you can write your first story for an existing component. And maybe you'll find that you get hooked there. The add-ons like knobs, add-ons like running tests in Storybook and add-ons like running animations in Storybook, you can get there. If one of those is exactly the thing that you want in your proof of concept, by all means, try to start with it. But I think you can start with even the most basic of cases for some UI component you've got laying around. Just take the first 15 or 30 minutes to bring it up into Storybook and see if it doesn't cause you to catch the bug. 

JC_HIATT: Yeah, and I'll also take a second to give a plug to a course on EdCad that I've actually gone through by Sean Wang. He's also known as Swix. You probably know him if you're in the React community. Yeah, he if you're in the React community specifically, he has a course called Design Systems with React and TypeScript and Storybook. That one's available on Egghead. It's pretty short. I think it's like 30 or 40 minutes, but it's everything you need to get up and running and add a couple of knobs and things like that. So I think that was especially helpful and it's very succinct. 

DEAN_RADCLIFFE: Oh, that's great, yeah. 

JC_HIATT: So yeah, do you wanna go to picks or do you have anything else that you would like to share with the audience? 

DEAN_RADCLIFFE: Just that, like, I think that we see async is hard and that seems like a problem that everyone is facing. I'm really actively involved in looking for good general solutions and I think that the more that we can write bulletproof code, that we have confidence that it's bulletproof, the better off that we're going to be as a community. I kind of see that as like the biggest open question. I believe that I'm onto a few things, but I'm trying to wrap it up in a nice little consumable package called the RxHelper library, because I think that a general-purpose solution to async can be built on RxJS and RxHelper is just designed to be a slightly easier on ramp. So I've been putting over two years into just collecting and refining those ideas. I'm thinking about a 3.0 for RxHelper that'll be even less code. 

JC_HIATT: Cool. Yeah. And we'll add a link to RxHelper in the show notes if anyone's interested in checking that out. 

DEAN_RADCLIFFE: Cool. Thanks, Jaycee. 

JC_HIATT: Absolutely. And if people have questions about Storybook, RxJS, RxHelper, what's the best way for them to get in touch with you? 

DEAN_RADCLIFFE: All right. So I'm on Twitter. The handle is deeniusol. That's short for deenius solutions. On GitHub, I'm just...I work at g2.com and there'll be some blog posts. I'll put a link to the engineering blog. It's actually not yet ready, but I'll do that. So, but basically between Twitter and GitHub are the best places to talk tech with me. 

JC_HIATT: Cool. Yeah, we'll add those links as well in the show notes. 

 

One of my favorite communities in programming these days is the Angular community. Every time I go to an Angular conference or meet up with some of my friends who are in the Angular community, I have a great time. And a lot of them have wound up on Adventures in Angular. So if you're doing front-end development, you're looking for a way to keep current on the Angular ecosystem, and you want to have a good time listening to fun people talk about great topics related to Angular, then go check out Adventures in Angular at AdventuresInAngular.com. 

 

JC_HIATT: Let's go to Picks. Are you familiar with Picks? 

DEAN_RADCLIFFE: Sure. As a banjo picker, I tend to have at least three of them on my fingers at any one time.

JC_HIATT: Are you also a dad by any chance? 

DEAN_RADCLIFFE: Oh, yes, sir. 

JC_HIATT: Yeah, I picked it up. Nice dad. 

DEAN_RADCLIFFE: Because of the lousy jokes, yeah. Ha ha ha. 

JC_HIATT: Cool, well, you got a pick for us today? 

DEAN_RADCLIFFE: No, these should be non-tech or tech related. Do you have a preference? 

JC_HIATT: Can be anything you want, man. 

DEAN_RADCLIFFE: Anything I want, well, I did wanna just really, I'm really on this animation kind of theme and front-end development theme and the one thing that I've been looking to consume more of myself is a series of videos by the key framers and that's at key framers. And this is David Kay and one other who they basically just for fun, they pair and they develop crazy things that you might find in the wild like a pure CSS dog looking in different directions tracking your mouse. You know, and they just chat it up and they develop it live in front of you. And it's, it's pretty neat. There's a, there, there, they, they only deal in the kind of creative things. There was a, a chocolate bar that bites get, you know, chunks get taken out of it. Deep CSS and a reactivity stuff in a really consumable format. I really want to watch more of them. 

JC_HIATT: Awesome. Yeah. I'll check that out. 

DEAN_RADCLIFFE: What do you got? 

JC_HIATT: I got a couple, I guess, technically both non-technical. Um, that's a weird. So first off, I recently went and saw the new Joker movie. I will say it is very dark. So if dark is not your thing, you may just use your own discretion. But I really did enjoy the acting. I thought it was absolutely brilliant acting. So going to pick that. Also going to shamelessly plug Devlifts. I am trying to get our mobile app actually done before New Year's. So if you're looking to get fit, or if that might be on your radar for maybe a New Year's resolution or anything, get in touch with me or check out our site, devlist.io. But yeah, that's kind of what's going on in my world these days. 

DEAN_RADCLIFFE: Very cool. The fitness thing, Charles brought that up as well, because he had just done his first marathon. 

JC_HIATT: I think he's been really into it for the past couple of years now, tracking different things. And yeah, we've had a few good discussions. 

DEAN_RADCLIFFE: Yeah, our family is all about fitness. And when my wife did her first marathon last year, she ran with a group called Action for Healthy Kids. So that is certainly worth a plug as well. 

JC_HIATT: Oh, yeah. Cool. I'll add that to the show notes as well. Cool. So yeah, it was a pleasure talking with you today. 

DAN: Thanks. You too. 

JC_HIATT: I really enjoyed our chat. 

DEAN_RADCLIFFE: All right. Look forward to hearing more. 

JC_HIATT: All right. 

DEAN_RADCLIFFE: Bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.