Duration 20:35
16+
Play
Video

Thinking Reactively: Most Difficult | Mike Pearson

Michael Pearson
Senior Hero Dev at HeroDevs
  • Video
  • Table of contents
  • Video
ng-conf 2019
May 3, 2019, Salt Lake City, UT, USA
ng-conf 2019
Request Q&A
Video
Thinking Reactively: Most Difficult | Mike Pearson
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Add to favorites
18.04 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Michael Pearson
Senior Hero Dev at HeroDevs

Mike was drawn into web development 5 years ago by a side project he started while in the physics program at Brigham Young University, and has worked as a web developer ever since. He loves abstraction, automation, preventing wasted time and helping others understand difficult concepts.

View the profile

About the talk

Reading and writing reactive code is a mysterious art that evades mastery for all but the most dedicated of disciples. Why is it so mind-bendingly difficult? Is it worth mastering? Most of all, how can we make it better?

ng-conf is a three-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1500+ developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.

Follow us on twitter https://twitter.com/ngconf

Official Website: https://www.ng-conf.org/

Share

So a few months ago and you kind of did a survey and the number one thing that angular developer said that both day and other developers are struggling with was rxjs. And when I was first learning rxjs, I thought that the most difficult thing was going to be learning The Operators cuz they're just so many of them. But once I was familiar with some of them I realized that I was still having a lot of trouble with rxjs and and talking with my co-workers and trying to figure out what why it was so difficult. We came to the conclusion that that it's more about thinking reactively

using those operators to build reactive applications that so difficult because it's just different from what we're used to and About a month ago or a year ago. Sorry. I was working on a tournament app where users could follow different teams and get notified Whenever there is a win or a loss for the team the following and there was a problem where the users were getting notifications when they were supposed to with with of teams are already following but then when they went to a team's page and and click the follow button, they didn't start getting notifications for

that team until they refresh the app. So I figured all right. I think I know what's going on. I ain't there is an NG on and it somewhere and in that Angie on Annette the app is taking the users teams are already following and I'm going through them and subscribing to the notifications so they can show them to the user and I thought it would be and but then in the event handler for the follow team button. There there was a missing line of code there. So I thought what it would look like if something like this so

you add that new team to the teams that the users following and then it would update some visual indicator in the page that they're now following that team and then that would be it and I thought that I could just come in and add this line of code and then it would just work perfectly. So just subscribe to the new notifications for that team and but my plan didn't work out and you'll never guess why because that function didn't exist or it didn't exist in anything close to the form that I was expecting it to so I saw this instead I was like

Okay. Click through to the definition for that observable and is just a regular subject. So I'm like, okay, I searched the project and found about 82 references to the subject and after a couple months, I finally found the right place in the code to change and then it worked so to step back for a second and think about that process. I don't think that's actually an uncommon process for a lot of people debugging rxjs applications. I've heard a lot from from other

developers and I've had this experience to where you feel like you have to chase the observables around, you know, the following the streams around until you find the right place to change stuff. So is it just rxjs? Is it is that the problem is it just difficult to debug rxjs applications? And usually that's kind of my go to approach, you know blame the code like a Skinner here. Am I likely experience? No, see if there were balls that are on but Actually, that wasn't the problem. The problem was my experience. My experience was mostly with imperative

architecture. And so I was thinking of it as an imperative app when it was actually structure like a reactive app. I think that's the key to making it easier for us to understand rxjs apps apps that are built completely with the reactive architecture. So to look at the difference between imperative and reactive I think is the key. So this is what we're mostly used to the function. Is that the unit that that determines how things behave you have event handler has call backs that are making things go to the server making things show up in the Dom and just

making things in general happen in your app. So when you have a bug you go to an event handler or call back and you expect to see the problem there expect to see something missing there. but with reactive apps Constructive structure kind of like this you have sources and sinks in a purely reactive app. And in the sources, those are things like Donnie van slyke when he's a types of clicks and then you have like server events or data arise from the server or timers. Just any time. Did it enters your app? That is a

source and then the sink is where data ends up after goes through your app. So that would be like the Dom where it's shown to the user or the server where it's saved. and so these are pretty different architectures if I flipped back between these two. So what was happening it was I was looking here for an event handler 222. I have that bug that I could fix but what I needed to do was actually start from the template and finding a sink pipe for a similar behavior and trace it up there. And if

I'd known that I would have found the problem in about one-tenth the time so Our habits are making it more difficult for us to work with rxjs apps. And it's even more difficult when you're trying to write. Rxjs apps so I've got this example. That I made in stackblitz. I hired a PhD graphic designer help me design this. Thanks. Yeah, so there's a certain pattern that I see that shows up in a lot of different apps and my favorite example of this pattern is a simple type of head or autocomplete or I'd like a list that

you're filtering. Based on user input and every time the first few times most developers come across this pattern they they make a mistake and they don't utilize the power of the rxjs gives you so what the what the type of hat is is basically you give it in foot and then it filters the list will that was an exciting I filter the list down to the string that you've typed and and then yeah so handles user input such as the date and then shows it. So how would you just naturally go about coding this

this Behavior? Well, The most natural method to every developer I've known as just go to directly the function takes care of it. The function is in charge the event handler to this to this input is right here. So you receive the search term then you go fetch the data. And then you show the data by assigning the the class property to that value and then change it texting takes care of the rest. So how does this work pretty well? but every once in awhile there goes

You get a mismatch between what the user has typed and the results that are showing you can alleviate this a little bit with the bouncing, but that's adding some permanent. Delete. I'm on the request that that maybe isn't perfect and it's it's also a little bit inefficient because once those requests are sent out they're just out there and they're not being cancelled. So what happened here was the second last request came back after the last request so it gets shown instead of the last one and that's where this problem comes from.

So how would this look if we were doing this more reactive Lee? well We would think about the sources and sinks and then the pipes that connect them and I really really like Deborah karatas talk on on Wednesday about this about, you know, creating these adorable chains that are composed that that allow you to not even need to manually subscribe. So that's kind of the approach I'm taking here. So I think about the source first is going to be a subject. It could be a behavior subject whatever but with the

subject. There's an event handler here. We're just going to pump those values into that subject and that's the source, okay. And then the sink I'm just going to say is going to be the casing pipe and it's going to Loop through the data and show it here. And so where does this adorable come from? This is the hard part. It's it's the part we have to think reactively because you have to do you have to connect to the source to the sink. And in this example, it's pretty simple though. You just chain off of that search term

and switchmap it into the filtered results and the result here is it's never going to be out of order. I guess just trust me. All right. I think that's enough with that. So what are the differences between these two approaches that we can extend to other examples and give ourselves away to? Avoid the imperative habits that we have with our code. Well, there's some differences here, but I want to call attention to the manual subscription hear. The imperative example is calling. Subscribe on that observable chain, and I'm looking over a bunch of different examples of Arceus code that

was still kind of an imperative style. This was the common theme between all of them. They were there were coding with rxjs, but they weren't getting the full advantages and they were subscribing and either the component class or the service. So Theoretically you shouldn't ever have to manually subscribe though. I I like the approach of of you letting the AC pipe handle at all because nothing really happens in your app. Unless a consumer is interested in it like the user and nothing is really been calculated unless it's going to be displayed right

eventually. The user is going to see it. So it's going to end up in the template. And so if you're if you're just connecting from the sources to the sinks and you've got observable change that are just composing each other all the way down. Then that that subscription to tasting pipe is automatically doing for you should just propagate all the way up to your code and you can have reactive streams and never need to subscribe. Manually. I'm not saying that you should never ever subscribe manually. I'm just saying that you should be aware that when you do

you are breaking that observable chain. And from this point on you are moving over to imperative code and you might not get the guarantees that reactive code gives you. so I think the one thing I could say is just of course. It's easier to code imperative lie because that's what we're used to but I think we can actually get better and more comfortable with thinking reactively. and and so I would say don't as soon as you get uncomfortable don't bail yourself out with this

subscribe and then do things imperative Lee. I'd say push yourself a little further and try to think of the reaction solution and that's how you're going to get better at it. All right. So the last part of my talk is just going to be a lot of opinions that I've developed. I I I'm afraid that that we might not get the benefits as a community of of reactive architecture fully unless we we really do put in like a an intentional effort at training ourselves and our team members to learn how to use a variables in a reactive Manner

and I am afraid that there's like the pendulum that's really in favor of our kids right now is going to swing the other way and after a while if we don't see a ton of benefits from that we might push it into the corners of our apps and kind of minimize its its influence in our code, but I don't want that to happen because I really really love rxjs. I think it's amazing. Remember that tournament app. I was talking about the beginning that bug wasn't real because that bug wouldn't have been able to exist and an app it was actually structured

reactively because the notifications would be shown using a sink pipe. Right and those notifications be coming from the observable of notifications would be changing off of the team's observable. And so you wouldn't be able to follow a new team and add it to your teams without that Valley propagating all the way through it would have been impossible for that bug to show up. I think that bugs may seem sometimes like an inevitability in our code cuz they're always bugs but if you're intentional about

Analyzing the bugs and where they come from. You can actually Trace where they come from and eliminate entire categories of bugs. I think reactive architecture. It eliminates inconsistent state. and because you can't really develop a new feature unless it's already getting the values from Miserables which will be getting the values. They need exactly when they need it. So, I think it's a better separation of concerns fundamentally. Does each part of the app is its own authority on what it is what it means what it needs and what reacts to whereas with imperative

code. You have functions that are determining other parts of the app how they're going to behave and do it at different times and it's very easy to forget a step. You have to be very active and making the behavioral looking for happen. I think a good analogy between reactive and imperative architectures is with plumbing. Cuz Plumbing is done reactively. But if it were done imperative lie, if you needed hot water there might be like a hose on the wall that you can you grab a new you spray water into the water heater you turn on the

faucet for a hot water and then you send a text to the utility company. So it's not really surprising that that maybe if that was how all Plumbing was done that may be a lot of people would be forgetting a lot of those steps. so a lot of my opinions are just based on my own experience just being a web developer for the past few years and I think based on my experience that reactive architecture is Is scalable for the modern web whereas imperative isn't? And I might sound like a strong strong statement. Like we would have noticed before now if

imperative was impossible, but I will have to have it been doing purely imperative code in a long time. When angularjs was introduced many years ago, it was mostly imperative, but it actually had introduced a slice of reactivity to our apps and it was exactly that slice of reactivity. The developers loved change detection was reactive. It could have been called Dom reaction Maybe. And for why we didn't we did struggle with imperative habits. There were a lot of questions people saying how do I manipulate the Dom directly in this

circumstance, sir, or this circumstance? And if you remember eventually enough people told us about the angular way where you let the variable you sign the variable man, like the dawn react on its own. I think Redux ngrx is kind of continuing that Trend as well accept. It introduces The Layover activity to the application state. We're reducers react to the events that are happening in your app. I think we are still struggling a little bit with imperative habits with Redux as well where we

create actions that are nothing more than satyrs of state but Yeah, I'm a really good talk about this is Mike Ryan's talk about good action hygiene. I think you gave last year, but it covers his concept. So but I think we will we will learn the reactive patterns with Redux as well. I think and rxjs to me is is just kind of continuing this trend but it allows us to introduce reactivity to every layer of our app and I I think it's powerful to have one abstraction for a

synchronicity that that you can learn and and then you're good. You can just always use it and We are struggling with it. There are a lot of imperative habits it. I mean it's a lot to adjust to it once with rxjs. If you're going to use it everywhere, which I don't recommend doing at first but I think we will learn the reactive habits. And as a result, we will eliminate will just be an entire category of bugs go away. And so I think it'll be worth the struggle definitely. to summarize The

points I wanted to get across in this talk. I think the reason we're struggling right now so much with rxjs is because of our habits that we just developed with experience programming imperative Lee. But we can Master thinking rack reactively. If we stick with it, and don't bail ourselves out with a man of subscription as soon as we get a little bit fuzzy on what to do next. And lastly it's going to be worth the struggle the thing that's exciting to me. I love seeing bugs go away. But the thing that I love most is not having to

worry about what parts of the app I have to update or worrying about all the bugs that might come up when I'm creating a new feature. I can just chain off of an existing observable. And not even worry about when that observables going to get the valleys. I can just trust that it will so it allows us to develop apps faster and get more exciting features to our user. So that's what I'm excited about. I'm really really grateful. I was able to give this talk. This is my first talk ever and I thank you all for listening.

Cackle comments for the website

Buy this talk

Access to the talk “Thinking Reactively: Most Difficult | Mike Pearson”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “ng-conf 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “IT & Technology”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
177
app store, apps, development, google play, mobile, soft

Similar talks

Kim Maida
Head of Developer Relations at Auth0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Thomas Burleson
Enterprise Architect at Ameriprise Financial Services, Inc
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Deborah Kurata
Independent Software Developer, Consultant, Mentor, Speaker, and Trainer (C#, Angular, TypeScript) at InStep Technologies
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Thinking Reactively: Most Difficult | Mike Pearson”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
731 conferences
30008 speakers
11213 hours of content