Introduction to Redux-Observable

okay we'll probably get started looks like most people are here yeah my name is cam I recognize most of the people in this room so if I haven't met you before hello and yeah this is going to be a relatively high level boot camp on what Redux observable is as well as a bit of a shallow introduction to rxjs because I'm going to be showing code samples a bit of a disclaimer is that this is not a boot camp intended to teach you rxjs it's definitely something that you should probably go and learn at your own pace I will link some really good like tutorials to get you started with your own learning as well but generally this will help you kind of understand how it fits into the stack and what sort of problems you're going to be solving using Redux observable so yeah before I launch into it I just want to kind of gauge the rooms familiarity with the existing like react Redux stacks so - any sort of asynchronous behavior so could I get a show of hands so people who use react and redux everyday as part of their job okay that's awesome how about people who might use react everyday but not necessarily a state framework like redox take one more people and then people that are just kind of familiar with the ecosystem or they've used react and redux for like pet projects that sort of thing yeah a couple more and yeah finally people who aren't familiar with react or redux like at all okay just a couple so yeah apologies to those people I'm going to be doing like a very quick whirlwind overview of the react Redux flow just so that we're all kind of on the same page to get to the exciting and difficult part which is redux observable but yeah if you're starting with the hard stuff if you actually go and learn react Redux it's going to be a breeze compared to this so yeah that's fine so yeah so this is basically a diagram a very simplified diagram of the reacts Redux flow on the right here you can think of your view as your react components I like to think of them as functions that just take your application state and return you a rendered view and so when you kind of hook up Redux it gives you like the concept of a global application state and you're going to bind like UI callbacks - dispatching actions into redux these actions are going to run into Redux reducers and these are just little cure functions that take the previous application state the action that was dispatched and they're going to return you a new application state based on processing the action that was dispatched and kind of the core principle of redux and what makes it so nice to work with and gives such good dev tools is that our reducers have to be pure so you can't perform any side-effects in your reducers and they also need to be items potent so if you call a reducer with the same state and the same action you're going to get the same resulting state as a result no matter how many times you call it and so yeah this is what gives you things like time-traveling debugging and like very easy predictability basically all the reasons why Redux is kind of the accepted state management framework for react but this kind of begs the question as to where do I actually perform my side effects where do I actually do things in my application that need to effect changes to the outside world or receive data from the outside world so cinema some examples of side effects would be things like network requests analytics any sort of logging basically anything that doesn't synchronously involve a change to your application state it might involve a change to your application state later on in the case of something like a network request but it's not something that you can just immediately process when like you receive a request from the view for example and there's kind of a broader question that redux has an app doesn't have a good answer for which is how can I compose simple UI actions together in order to create actions that are more meaningful to my application state and by meaningful I mean things that can just be immediately reduced and so I used drag and drop as an example your simple UI actions might be things like Mouse down mouse move Mouse up but in order to actually update the position of a thing on my screen I need to kind of have some awareness of what the currently selected card is or whether my mouse is even down and so if you just have their simple UI actions if you try and kind of compose this logic it's going to leak like implementation details or your redox state things like what was the the currently selected card like is the user holding the mouse down and like these are things that I don't personally think belong in your redox state ideally it should just be like a very simplified version of something you can derive a view from and so stuff like that is really about tracking like a long-running process that might occur within your application so there's no real good answer for that in redux as well and so when we made core boards we weren't fortunate enough that something like Redux observable or Redux saga existed at the time so we kind of rolled our own solution that's very similar to Redux thunk if you're familiar with that but effectively it's a way that you can just instead of dispatching an action you can dispatch a function instead and just do any side-effects you want and then emit actions as a result of your side effects the main problem with this is really good for like simple isolated Network requests and that type of thing but you kind of lose sight of like what actions have actually occurred before me like where am I within this sequential process and that's something that both redux and redux observable and redux are I have a really good answer for yeah how does it look sitting next to the existing Redux flow it's basically this like little isolated box that sits next to the normal like dispatching action reducing rendering my view slow and basically you it's an isolated box that takes all actions over time time being very crucial as input and has the ability to emit new actions that will also just feed into the normal flow and so because it's just dealing with actions as a contract it's it's really cleanly next to redux and things like time traveling and all of the good things about redux still remain intact because your reducers remain pure yeah before I dive into the specifics I just want to kind of gauge how familiar you how familiar you guys are with the concept of a stream and more specifically an event stream so could I just get a show of hands people who've used the Java 8 streams API for example ok that's really good something like blow - or underscore awesome and then just the the functional primitives things like that so reduce that sort of thing yeah okay awesome and so before I started like kind of programming in the FRP paradigm I typically use streams or like the functional primitives like as a substitute for a for loop so I had like a collection of things in memory and I want to transform them in a way that I don't have to break out into a for loop and like build up a new state of things over time it's much easier to read like a chain of functional primitives when you're transforming something and it's also cure which is really important and really good so if you kind of take this concept further FRP or functional reactive programming is a paradigm that lets you operate on a stream of things that like might not even be there yet but you operate them on them in the same way as you would as a collection that exists in memory which is a really powerful paradigm because it means that once you've written your logic you've kind of defined all of the behavior that can and ever will happen in your application like all of the plumbing is there and then when the interactions are actually occurring you just have stuff running through that plumbing but you're not you're not moving anything as the application runs which is really cool but yeah the official definition of a stream in this sense is a sequence of ongoing events ordered in time and the time part again is really crucial and it's going to keep coming up again and again it's kind of one of the core things that you'll be dealing with when your program English streams and so this is kind of a good opportunity to segue into what I think is a very useful visualization of operating on streams and this is called a marble diagram this is a really simple model diagram dealing with the merge operator from rxjs and basically how you read these things is you have two or more input streams or sometimes there's one input stream you have the operator and then you have an output stream and so the important part to notice is that it's maintained the time semantics of when things were happening on your input streams and different operators will obviously handle these time semantics differently so if I actually go and show you an example of some marble diagrams so this is the merge one this is a site called rx marbles comm it's fantastic because it's marble diagrams are actually interactive you can move things around on your input stream and it's going to actually be invoking that operator and you'll see the result of the output stream hopefully I don't get another one of those and so if you're looking at a model diagram and you don't really understand what the operators doing from looking at it statically you can just have a play around with the input streams and it's going to become really apparent what the purpose of that operator is so yeah does this make sense does everyone kind of grok what a marble diagram is and why they're useful cool and so this is a there's actually even simpler one so this is your map primitive and it's just like mapping over a collection except obviously you're maintaining the time semantics of when things were emitted on your input stream but you can just perform a simple transformation and I'll get the transformed value emitted on my output stream there's also modelled diagrams for things that are a little bit more complicated something like combined latest so combined latest is any time any of your input streams emit a value you're basically going to take the latest value from all of your input streams and feed them into a function where you are able to combine them in any way that you see fit don't worry too much about the specifics of combined lattice I just want to show you that marble diagrams are useful for even more complex operations and the first time you look at this you might not understand what it does but you absolutely would if you started moving things around and having a play with it so yeah that's that's marble diagrams so we kind of touched on rxjs those were specifically marble diagrams for our X operators but it's kind of an important distinction to make is that rsjs and FRP are not the same thing so rxjs is an implementation of FRP and there's tons of them so even just in JavaScript you have things like bacon Kaffir Highlander rx obviously Xtreme that's probably like a dozen more but rxjs is definitely the most mature and it seems to be the one with the most like developer mindshare there's bindings for our X in pretty much every language that you can think of I'm pretty sure our X Java is just like a standard part of the Android development stack as well so it's a are you like well regarded mature library and so it makes sense to use it here because yeah so yeah I like to think of our Xterra - for events in the sense that it's just a bunch of convenience methods and utilities to help you deal with programming with streams it's important you kind of separate that concept from FRP and stream programming in general our staff is there to just help you with convenience operators it's not there to dictate like what stream programming is and yeah this is this is the hard part of learning to program with Redux observable is that you will end up having to learn our Xterra and for a lot of people if you're not already familiar with FRP you get to kind of been learning a library and the new paradigm at the same time which is pretty hard to do and it's going to take a while before it clicks but it will click and then you're going to want to write everything in this way because it's very declarative and I think it's very easy to reason about and yeah that's a shitload operators there's something like 60 to 70 operators in rxjs just as an example I think the issue out we use like four or five there's going to be some that you like very commonly reach for for things like making a network request or making a get request or doing things like - bouncing but you're pretty much guaranteed nearly because of how many operators that there are that if you can draw a marble diagram that models your specific problem they'll probably be an operator that solves it for you and so multiple times I've like rolled something more complicated myself using the operators that I already know about only to find two weeks later there's an operator that solves my exact use case and so it's kind of a good idea just to even if you don't understand every operator have a general idea of what kinds of operators or the families of operators that are available to you before you dive in and start coding so yeah we've touched on rx you kind of know what a stream is we know what Redux is so what is Redux observable specifically I showed you how it fits into the flow but what is it and what is it doing under the hood so Redux observable basically introduces a new primitive called an epoch and an epic is specifically a function that takes an action stream so if you ever see this dollar sign just read it as the word stream it's kind of like a convention that you want to name a variable that is a stream because we don't have types or maybe some of you have types but we don't have times and you return a new action stream which will be your output stream and anything emitted on that output stream will just feed back into the normal Redux flow and so kind of at a philosophical level this is really powerful if you think of that stream of actions as your user it's like all of the interactions that your user can perform in your application over time you've stored your user in a variable in your app and that's not really something that you can do and many other paradigms and I think that's really cool so it's your job in an epoch to operate on this action stream that's coming in as everything that will be dispatched through your UI through redux you want to operate on this using rxjs operators and produce a new stream of actions that will be your output and they will feed back into the normal flow an important gotcha is that they will also feed back into your epics as well like every time you emit something from an output stream it's going to go through the entire Redux flow so you there is potential to hit infinite loops if you're not careful but yeah it's something to watch out for the coolest part about Redux observable is that you basically get to ignore what I think is the hardest part of LearningRx and when you go and learn when you go and look at the tutorials there's going to be a lot that cover these specific topics but things like managing subscriptions the difference between hot and cold observables you just don't have to care like you have a very narrow contract to be writing these stream operations in and redux observable takes care of everything else for you so it's really good ah so does that kind of make sense to everyone is there any questions so far with Redux observable okay cool oh yeah that that's spin so that's their logo so the RX logo looks like this and then they've kind of put ducks in there because Redux and yeah so solving a problem with an epic so let's say I have a new problem that involves some side effects or some composition how would I approach actually solving that problem with an epic and so the first thing you're going to do which is a good idea whenever you're solving a problem is to like describe it in detail what you want to do when you're using rx though is pay particular attention to any of the like timey keywords that come up in your problem description so to use drag-and-drop again as an example because it's a really good one like a drag moves action that would actually be updating the position of something on your screen you can define one of those as being when the user clicks down every Mouse move until the user list their mouse and so those keywords like when and until are kind of going to point you in the direction of the rxjs operators that are going to be a huge help to solving a problem and yet take until is a perfect operator for doing drag and drop you can do it in like two or three lines and so yeah you're going to want to isolate your time semantics try and draw marble diagrams to illustrate the problem that you're trying to solve it will help and you'll probably catch your own edge cases in the process of trying to visualize it and then you're basically going to want to do a comparison between your marble diagram and the rxjs documentation or the existing marble diagram and this step will become easier and easier the more familiar you get with the library but yeah that's that's probably the hardest part of this at the moment and also a massive hint is that test-driven development can really help especially if you're unfamiliar with rx because even though it's this little black box it has a very clear contract of inputs and outputs and so it's inherently very easy to unit tests so I would strongly encourage you to write your unit test before you write the epic because then you just have a clear wind condition and that's just test-driven development in general which is a good idea and so we have a utility in JIRA front end if any of you aren't working in JIRA front end I can link this utility but it's called test epic it basically takes three functions as parameters arrange act assert which is like a normal unit test in your arrange method you're going to set up any mocks for the side effects that your epic might be performing and actually create your epic and returner and then in the act method you're given the input stream so it's your job to basically push things on to this input stream like you're pretending to be Redux or pretending to be your user and then you call complete on it when you're done because streams live forever and you need to actually tell it when you're finished otherwise moco will timeout or not finish your test whatever and then that completely kind of triggers the running of your assertion method where you just get a flat array of all of the actions that came out the other end of your epic so using a network request as an example you're probably going to put something like a request action onto your input stream and then in your assert method you're going to expect that you've got a single success or failure action coming out the other end without knowing anything about the epic underneath that I kind of know that that's the behavior that I'm expecting from that epic okay so we're going to look at some code samples big disclaimer it will look very alien if you're not familiar with our X but we'll kind of walk through some simple ones and then a not so simple one line by line so you can just gain an intuition as to how FRP programming feels so yeah we'll start with the simplest example reality is nine times out of ten you probably just want to do a network request in your app so it's probably a good example to start with is a very stripped down get request this get request isn't doing any - bouncing it does handle concurrent requests which we'll get into but yeah it's basically responding to a request action and emitting a success or a failure action with the appropriate payload that came back from the server and so the export here is the actual epoch so I'm taking the action stream which is by stream of any action that was dispatched through redux and I also get access to the Redux store and this is really important because you can call get stayed on it at any time to get the state of your Redux store so if you have things like your logged in user or like what pagination you're up to for a network request something like that it's probably going to exist on your Redux store and so you can access it in your epoch and so on this first line this is very typical of what an epoch will look like I'm dealing with all of the actions but I'm only interested in one in order to kick off my request in this case the fetch license details request action and this is just a normal action from redox and sorry whenever I receive one of these I'm going to do something called switch math this is part of in my opinion the most scary family of operators in redux in rxjs sorry but if you understand these they're also the most powerful so I like to think of them as like kind of walking like into an asynchronous process and typically this is what you're going to do immediately before you perform a side effect and what its contract is is that you give it a function that itself returns an inner observable and so the idea is that I'm kind of going to fork off this inner stream I'm going to perform my network request and then I'm going to map it into my success or failure actions and what's which map will do is basically flatten that inner observable so that instead of having like an observable of observables which is like an absolute Mindbender it just flattens this into a single stream of actions which is the contract that you need to adhere to as part of an epoch what makes switch map really special and why it's probably going to be your go-to operator for making gap requests is that it will handle concurrent requests for you for free so if you imagine that I have one of these actions come through and I'm actually performing my get request so I'm sitting somewhere in here fetching something from a network and waiting for a response if I receive a second fetch license details request while that first one is still being processed I effectively throw away the first one in favor of the new one and so you can guarantee when you use switch map that you'll never receive stale data and you don't even have to like think about that you will test for it to make sure that it works obviously but yes which map concurrent request for free it is important to note that is probably only forget requests because if you're doing a mutated request like a post or a put you probably are interested in explicitly every response that you get back from the server so you can tell the user if something went wrong and in that case you would use merge map otherwise known as flat map and it's exactly the same it has like the whole inner observable that it's going to flatten but it won't throw away the old one it will actually maintain all of the old inner streams and emit all of their results on your output stream the final one is Concord map which is you will guarantee the sequence in which you receive those responses matches the sequence of when you have the inputs and so that's usually the case if you want to like avoid any sort of race conditions so if my first request actually takes longer than my second request concat map can give you that like ordering for free which is really helpful so the next line here so in a little inner observable this has kind of been abstracted but you can think of it as just a window fetch we have a fetch JSON stream wraparound window fetch and this just turns a promise into a stream and so a promise is you can think of it as a very knobs very narrow subset of what a stream offers you in that a promise explicitly emits a single value and then completes and so by turning a promise into a string you're turning it into a stream that will emit one value and then complete itself and so that's what this wrapper does so this return will be an observable that's going to emit the results or the resulting payload of my fetch request so after I've done that here I'm now mapping over it so I'm assuming that I've got the results of my request feeding into here and I'm just using a normal old Action Creator from redux in this case the fetch license details success action creator and so it's going to take as its argument the payload that it received from the server it's going to dispatch a normal Redux action and the whole flow is just going to continue as normal so the way that so I'll get into this a little bit later the way that error handling works in rxjs is a little bit funky and it's definitely one of the gotchas but basically if anything goes wrong in this inner observable I'm going to replace that entire inner observable with this one instead and in this case that's just going to be an observable that miss emits a failure action and so switch maps going to flatten that into my output stream and it's kind of a way of guaranteeing that I either get a success action or a failure action based on what happened in the network does that make sense to everybody that was probably a lot kind of that's good what might actually make it a little bit clearer is if we look at the tests for this thing so the first test is the happy case I should emit a fetch license detail success action with the expected payload when my rest call succeeds so I'm using my test epic utility here in the arrange method I'm mocking out the call to fetch JSON and I'm simulating a successful Network request and then I'm setting up my epic and returning it to the arrange method and then in my axe method I'm pushing a fetch license details request action on to my input stream this is simulating that the user clicked refresh or something and actually asked for a request and then completing it because that's all I'm interested in doing and then in the assert method I'm making sure that because I'm opt-out a successful request I get a successful action with the appropriate payload similarly for the sad case we mock out a failing Network request we do the exact same thing in the act method which is putting it pushing a request action on to my input stream but I'm expecting that I get a fetch license details failure here instead and so you can imagine if this more granular handled errors in a more granular way you could expect different failure actions with different payloads based on what went wrong with the request and so you could write unit tests for that and so this last test is actually testing the switch map behavior and so this is basically on it's also a good idea when you're testing something like multiple requests that you make a test that has a failing thing first and then a successful thing after the reason for that is the Gotcha that I mentioned earlier with the way that error handling works if you don't handle your errors in this inner stream and instead it bubbles all the way to this output stream or you get a runtime error that bubbles all the way out and it's uncaught your epik will close and while it will complete and so effectively it won't be running anymore and so if you don't test that it survives a failure you can get into a case where your epik just dies like at the runtime of your application which really sucks it's a bit weird that our excuse is to do it that way but I think I was one of your questions related to that but how to catch at this like a top level of the epic and it will result in your stream closing so it's definitely something to watch out for and so this test is kind of checking that so it's doing a felling request and then it's doing a successful request I'm pushing my to request things the reason I have to do a set time out here is because of switch map if I did it synchronously switch map would just throw away my first request and it wouldn't actually get to the point where it hit my mark or if it did it would be because of a race condition so I'm just basically forcing myself to be on the end of the call sack to make sure that that first mocked request actually ran and I'm doing another request then I'm making sure what came out the other end is a failure and a success action specifically in that sequence as well which is another important thing see out of these tests make sense does that make it kind of easier to understand what the epics doing under the hood okay good I'm seeing notice all right so let's go a little bit more complicated so this epic I might demonstrate the behavior first because it'll make it a little bit easier understand so this is the epic that involves fetching the suggested assignees in our assignee picker when they use this typing something our mock request for this doesn't actually match the query we just get the same results back every time so you won't actually see it filtering the results but just so you kind of understand what's happening it's the epoch that's populating that like autocomplete box so alright so the first thing I want to draw attention to in this epoch is the effect is the fact that you can kind of break up a particularly complicated epoch into these little mini sub epochs you could just merge them together because they're just streams you can put them all on a flat level and they're all going to operate in the exact same way on the exact same action stream so you can basically separate an epoch on any dot so something makes sense as like an isolated unit you can totally just put it in a variable or put it in its own function declaration and treat it in isolation and then also test it in isolation which is a really handy thing to do and so we have these two little sub epochs here and what these are doing so that's actually the second interesting thing about this this is like the core functionality of the epic this is the thing that's actually doing my network request and you'll notice like the example that I showed you earlier it's filtering for this specific action type the fetch suggested assignees request what's interesting about this epic is that that request never comes from the UI that request action actually comes from either of these two little sub epics and that's because we have generic actions that operate on a field without knowing or caring what that particular field is so we have just simple actions that will fire whether I'm updating the summary or the assignee or the description and these are things like edit field update and edit field begin and so I can use these two little sub epics to turn an update on the assignee specifically or when I begin editing the assignee into a request without the UI having to know that a request needs to take place and that means that this epic actually holds all of the logic necessary for fetching the suggester designees and populating that box none of it leaks anywhere other than this particular epic which is really nice in order to like reason about any bugs that it might have but also for testing purposes as well and so yeah these two little mapping epics they're looking at the payload of my edit field update action and if I was updating the assignee I'm going to turn it into a fetch suggested assignees request when I say turn it into I don't actually mean that I'm changing the action that edit field update will still go all the way through the redox flow but I'm additionally going to have this request action dispatch as well and the same deal for edit field begin so that's when the user first clicks into the assignee field I also want to fetch some initial results and so actually I might show that kind of happening so you can see on the Edit field begin I got my fetch suggested assignee his request and that was coming from the little sub epic and then I'm doing the network request and getting a success back and so we'll look at the the second part of that epic now I keep doing that all right so this is basically identical to the example that I showed you earlier it's filtering for a request action you can ignore this crazy second line we'll get back to that it's doing a switch map so that I handle concurrent requests I never get stale data based on the users query it's performing a network request in this case we haven't abstracted over such JSON we're just calling it directly so all of this logic is just about getting all the things I need to actually make the network request I do the network request and then on the lines after I can assume that I got the payload back from my get get request so I'm doing some transformation so that it is in a format that I want for my redox state and then I'm mapping it to a success action and if anything goes wrong in the in the request or in the transformation I'm instead turning it into a failure action so this is the exact same as the example that I showed you before except debounce so this is really cool and it's kind of it demonstrates the power of programming in FRP because you have this clear concept of time you can do things like the bouncing in a single line and so the way that the bounce will work is it's basically going to pause on that line so anything that comes through any request actions that make it through that first filter will basically sit on debounce for the amount of time specified by fetch to bounce time in this case it's a second and if any other requests come within that time it's going to reset that timer and continue to pause and wait for other things and so I only get to this switch map if I've received a fetch suggested assignees request and then no more for a second and so we can kind of demonstrate that behavior so I've got it set as a second ok so we go as my dev tools so they are okay so we're going to here I'm pausing for a second so I actually get my success come back but if I type quickly you will see that it doesn't scroll for me automatically you'll see that I'm getting these pairs of updates and requests probably a little bit weird that we're dancing the actual request action because a network request isn't actually occurring because that happened after the debates line but you can see that I'm not getting any failure or success actions I'm just basically stuck on that request line until I force for a second in which case I got the request and then the subsequent success so yeah one line the bouncing is pretty powerful but like all things it's a good idea to test it so we have some tests around to bounce behavior this kind of illustrates why breaking down your epics is a good thing you'll notice that they weren't actually separate exports but I can exercise their behavior as if they were independent epics so I have two test cases here that are just checking when I do an edit field update on the assigning ID I get a fetch request coming out of the epic and the same deal with when I begin editing the assignee I also get a fetch request and then just for the completeness when I edit the summary I don't get anything coming out the other end and then we have very similar tests to the first example where I'm actually exercising the network request behavior so I have like successful result marks failed result marks and I'm making sure that when I have a successful result I push my action on I get the success action come back same deal with the failure but with a failed mark and a failure action and then these are kind of interesting so here I've specified my fetch to bounce time and I'm making sure that if I do two requests within that time I only get a single response coming out the other end and I verify that my actual fetch stub which is the thing that makes the network request was only called once this is different to the switch map behavior so if I have a delayed request if I say that the request itself actually takes some time to run and I deliberately wait for longer than my to bounce time I'm still making sure that I only get a single result even though my network request was called twice and that's because of the switch map basically discarding the results of the first request call there yeah that was probably even more does anybody have any questions about the fetch suggested assignees epic or its tests on your face because a waiting on rival assailants yeah if the are you controlling combining or are you in line but the to be you stand around his partner actually 10 milliseconds to actually it's both but yeah so in this particular case I think we actually have a card coded but if you notice the the epic itself does take the DES bounce time as a parameter so yeah we can control it unfortunately there's I'm not sure if it's a bug on our X's and/or sign-ons and your fake timers don't work particularly well with our X I think it's a known issue and it is really annoying at the moment because you actually need to use real timeouts which is like terrible for your tests but eventually that should be fixed and you'll be able to use something like sign on fake timers to to mock yo to bouncing yeah that sucks is definitely another gotcha alright so moving on cool see I've mentioned a couple of these just in passing but rx has gotchas these aren't necessarily FRP gotchas they're usually things that rx has kind of decided to do that might differ from other stream libraries or might seem counterintuitive and I've definitely been bitten by them a lot before the biggest one is error handling basically any time you know that a runtime error can occur in your stream treat that as a massive red flag to be super careful to make sure your stream is robust enough to survive because it seems really strange that streams can live forever but if an error occurs they just silently die just be really careful about that behavior and write tests for it definitely the other one is that debugging I don't necessarily consider this a bad thing it's just different if you're coming from like a more imperative style of programming the way that like nothing's really moving at runtime you just have things like running through this plumbing log driven development is definitely the way to go so this little do operator in rx that basically just allows you to perform a side effect on any value that flows through that part of the stream and so nine times out of ten your problem is going to be either my streamers and emitting anything or it's emitting the wrong thing at the other end and in order to isolate where your problem is you basically want to use a do log and move it through each of the operators and make sure all of them are receiving the input that you kind of expect them to and that your console logs are even running at all because if they're not you know you might have some sort of bug in your like how you reason about the time semantics of your problem all right yeah any questions on those gotchas on error handling or log tripping development if you set up your IDE and you do test-driven development you will hit break points for things sometimes a little funky weather break points work or not when you have like this little one-line function like this I've noticed that sometimes work and sometimes not work but if you have something that's a little bit more broken out like the inner observable creation in that switch map if you put a breakpoint there it will hit it so yeah test-driven development plus using something like vs code that has like inline breakpoints can really help cool so that's pretty much it in terms of the content I have this last slide I will post these links in our redux observable who can hip chatroom I very very strongly recommend the first one if you're unfamiliar with FRP it's kind of like a grassroots introduction like written in layman's term analogy to what is reactive programming like why it might seem so complicated initially and it kind of dispels a lot of like the magic and the intimidation of using something like rx it's written by a guy called Andre Stoltz if you can find anything like written about reactive programming by that guy it's really really good he's one of the main contributors to rx and he just explains things that thousand times better than I possibly could and so yeah he's a very handy resource in his own right and he actually runs that three egghead rxjs series that I have linked as well there's actually multiple series run by him but I'm not sure if the other ones are free or not they're not is that one free okay yeah definitely watched that one at least and then bugged your team lead for an egghead just subscription like I did so that I could watch the others but yeah he will kind of take you through like creating your own observables as well as implementing your own like custom operators and as soon as you see that you realize that there's not actually that much magic happening under the hood a lot of it is just using JavaScript things like set timeout and set interval and it's just a it's kind of showing you that there's nothing to be afraid of when you're digging into the internals of something like rx because generally when you're learning to program with it it does feel very very magical and if you have some sort of intuition as to what's happening under the hood it makes it a lot less scary and yeah the last one is probably less important for learning but it's really good motivation for why we chose Redux observable and so it's by Gaia Netflix so if you want to wear Redux observable actually came out of Netflix they're big fans of rxjs they're big fans of reactant read arts and they kind of wanted to put the two together somehow and came up with Redux observable and there's some really good examples of like stream problems that can be very easily solved in streams that are inherently either impossible or incredibly complex to solve using any other paradigm and so a lot of the examples I showed you today probably didn't illustrate this because they are they would use much more complex features of rx so I stuck to things like making that work request but there are situations that you're going to be very glad that Redux observer is the abstraction that we chose to that oh yeah that's pretty much it does anybody have any questions at all about anything yes switchback yeah uh is there a model diagram for it I I think they just they gave up on rx novels but I think I think the it is it's hard to draw it's really hard to draw any of those like higher order observables I think the documentation tries but it looks weird as hell but let's find one oh yeah so this is another gotcha actually I should have mentioned that rx just very recently did a full rewrite from RS 4 to RS 5 and there are breaking changes so be really careful a link to correct Docs currently the Rx for docs still come up higher in the in like the Google search results but basically if you see purple you're in the right place if you see a github page you're in the wrong place so yeah make sure you're using the new Doc's most of its the same but yeah there are there are some breaking changes so please have a mobile diagram all right has one okay let's try and understand what this is so yes they've tried to model that in a stream as that little stream of three tens so it's like when I receive a one I'm kind of forking off and creating an inner observable that will emit ten three times but you can see that the output stream just has the three tens on it so the fact that it's kind of flattened that inner observable into like a flat output stream but yeah it's it not as nice as some of the other Marvel diagrams definitely that's why I tend to think of it as like a fork like I would actually draw a line like coming from the one there to say that I'm like I'm explicitly creating another stream so my input in a way is a stream of streams that gets flattened into just a single like stream of values but yeah hopefully that helps probably not but once you use these things like a fair few times you'll understand it and they are the hardest operators like Wi-Fi all of the others are just doing transformations on an input stream these higher-order ones that are going to bite you probably any other questions yeah so I'm very glad you asked that Michelle so I did want to very briefly give an example of something that would be really hard to solve without using something like Rx and I really like their example for sequence equal so if you ever imagined needing to implement like a multi key keyboard shortcut handler or a more fun example would be a cheat code so like up down left right a B to catch pokemon if that ever worked basically this operator will do all of that for you and if you weren't using streams you'd need some kind of like global array to handle like a time out and like what the last like entered sequence was and like whether the next press is going to match the other thing you can do it in like basically one line of rx no it's not really one line but this is not using reductions over so it's actually setting up like the streams that it needs to operate on but you can basically have a stream of your keyboard events and you can have a stream stream being like this sequence that you actually want to match which is code in this example and your output observable will emit something when that sequence matches over time you have the ability to very easily add like a timeout to that using like a buffer to make sure that they have to like very quickly enter the cheat code or more practically like the multi key keyboard shortcut and so if anybody uses then I really like to imagine like implementing an entire vim like plug-in just using sequence equal so that I can catch things that are like entered over time I think that would be like a fantastic abstraction and I've looked at some vim plugins code and it's horrendous and could be easily solved with something like this so that's my favorite operator cool yeah that's pretty much it from me I'll probably turn the hip chat room into just like a general redux observable questions and answers room I love solving these things I do have my own road map so I might not be able to like work on it immediately but I do really enjoy when someone has like a hard problem that hasn't really been thought of yet trying to solve it in like a clean way using our is it's just fun it's fun to be cool alright thanks everyone for going and good luck [Applause]

Channel: Cameron Fletcher

Views: 12,911

Rating: 4.7535543 out of 5

Keywords: React, Redux, rxjs, redux-observable

Id: zk2bVBZhmcc

Length: 46min 33sec (2793 seconds)

Published: Thu Jun 08 2017