The Big Elixir 2019 - Beyond Liveview: Real Time Features With Liveview - Sophie DeBenedetto

hey guys welcome to this stage with me this feels really like I should sing a song or something yeah I'm not going to you don't want me to alright cool so today we're gonna be talking about beyond live you building some real-time features with live view pub/sub presents and a new ish thing called live view hooks first I'm gonna reintroduce myself Thank You Bryan so hey guys I'm Sophie this is my dog his name is Moby he's really cute there are a few pictures of him in today's slide deck so please get ready F Bryan said I'm an engineer and a sometimes teacher at the Flatiron school and I'm also a contributor to elixir school which is a free open source elixir curriculum we always want lessons we always want blog post from contributors new and old so if you haven't come across it yet check it out and write something for us okay plug done actually one more plug I do want to kind of just give a shout out to my own team at the Flatiron school without whom I certainly could have done this or I really learned so many of the things that I have learned in the past couple of months and years so yeah just shout out to those guys as well okay so I want to begin just by taking a look at the roadmap for today's talk three basic sections first we'll be taking a peek behind the scenes at some live view source code to demonstrate that live view can in fact do just about anything because of the manner in which it wraps phoenix channels then we're actually gonna make our very own live view do just about anything by extending its functionality with the help of pub/sub present and presence and lastly we're going to be wowed definitely wowed by live use JavaScript interoperability functionality and it'll be a little less wowed but still very impressed when we take a look once again under the hood at some live view source code this time on the front end so yes live view does mean that you don't have to write a lot of JavaScript but today I'm gonna make you look at some of it just some of it okay so I want to jump into our first topic live view and phoenix channels live you just channels in disguise so it's definitely an oversimplification to say that live view is just channels and disguise live view obviously provides so much more functionality than channels already offer us but the features will be for the features we'll be looking at today I do want to zero in on the part of live view that really is a wrapper around channels this is the functionality that Ally allows Live View to transcend some of its seeming limits all right so why do we care that live view leverages Phoenix channels we already know that live view is objectively great studies have shown this four out of five doctors agreed it's given us the ability to implement flexible and responsive UI eyes almost entirely with server-side code and really not that many lines of server-side code on top of that we can build things like complex games we can handle things like form validations autocomplete user notifications if anybody checked out like the Phoenix frenzied competition submissions you know that the things you can do with Live View are varied and very cool and we can back all of these cool features with the concurrency and fault tolerance of elixir processes but Live View has limits or at least it seems to so I think as we use Live View for more and more real-time features we're gonna want to naturally reach for the other real-time functionality that Phoenix has promised does for example user tracking and message broadcasting so something like a chat app which is like the traditional phoenix channels example therefore not a good candidate for live view if we're building out a set of features that requires user tracking and broadcasted updates would we eschew live view and just go back to using channels would we do something like incorporating Live View into a page that's like already backed by these other technologies you can probably guess the answer to this question is no live you can do a lot more and the reason why is that it's really just a process and like any process we can teach it to send and receive certain messages but what do we mean when we say that Live View is just a process I read that a lot like in the documentation and a lot of the articles and blog posts that came out about live view live view is a process it's just a process and I wanted to understand where the process is in all of that kind of live view component source code so the live view documentation states that live view is built on top of channels and in fact when your app run a live view a live view channel is joined and this is the channel that receives messages and actually calls out to the live view module that you would define so I want to take a closer look at how this works we're gonna take a look at some live view under the hood also I do not recommend letting my job repair your car this picture is not a reflection of real life all right so let's say we have a live view backing our chat apps show page which is exactly what we'll be doing later on today let's take a look at the procedure that occurs when a user visits a chat room at the chat /id route the first thing that we would do is invoke live view controllers live render 3 function with something like the following snippet of code so you would have this and like the show action of our own apps chat controller we're calling live view control our live render 3 and I want to call attention to the fact that the second argument that we're giving to live render is the live view module that we would have or will have defined so this call to live render 3 is what kicks off the live view lifecycle before we look under the hood at the live render function now mind do a little announcement so the code that we're about to look at is not code that you would have to write in your very own live view to get things up and running the whole point of live view is that you don't have to ride this kind of code anymore I just want to draw a distinction between this would be like the one snippet that you would be on the hook for writing let's say in your own controller action everything that's coming up the source code okay so live view controllers live render 3 function in turn calls live use static render 3 once again just passing through our live view module which if you recall is chat live view a live view module that we would have to find a live view static render 3 is really where the magic happened it configures the socket with our apps endpoint and you guessed it our actual live view module the static HTML template is then rendered which fires the live view socket connect request the socket which remember has already been configured to know your live view module for this particular life cycle is also configured to route live view events to the Phoenix live view Channel and once the socket is connected the channel the climb there we'll send that channel join request and here's just a little peek it's a very simplified live view client-side code we can see that it's establishing a channel for the given live view with like a unique topic and then we're gonna join the channel via a call to channel join so this starts a live view channel process where that channels socket knows its corresponding live view module name since the socket once again was configured with this way back when we static rendered so later when the client sends an event up that live view Channel the live feed channel is gonna look up the live view module from its socket and invoke functions on that module and once again a very simplified look at some live view source code this is the live view Channel we can see that when the channel receives a message from the client it's gonna look up the live view module from the socket and really just call handle event 3 on it passing in the event name event value in the socket itself so live you at least in this sense is a wrapper around phoenix channels and it exposes an api that abstract away a lot of the repetitive setup and a lot of the JavaScript that channels leaves us on the hook that's a pun for later for writing so if you kind of think back to some of the source code that we just Pete that it probably feels really familiar to you from having worked with channels yourself you're familiar with like setting up your socket pairing it with a channel writing some socket connect and channel join code on the front end and writing some logic that handles events in the channel so one of the really cool nice things about live you if you don't have to do any of that at all which is pretty cool okay so now that we can see exactly how Live View is built on top of channels it probably won't surprise you that we can therefore use Live View together really easily with Phoenix pub/sub and presence and we can even hook into events that the channel sends down to the client in response to change state changes on the backend will do that by leveraging live view hooks which we'll take a look at later on alright so let's do it and this talk we're gonna build a chat app entirely backed by a supercharged live view it's gonna incorporate pub/sub presents and hooks to give us all the real-time functionality that any respectable chat app offers its users let's take a look at the features that our chat app needs to support so we'll certainly have real-time messaging anytime a user submits a new message everybody in the chat room should see it we'll have some user tracking on a nice little list of everybody who's present in a given chatroom and we definitely need to have a responsive UI anytime a new message shows up in the chat we want our chat window to scroll down so that everybody can see it pretty standard stuff okay so to revisit our roadmap the first of these two features brings us to our second topic on the roadmap extending live view with pub/sub and presents and we're going to begin with our very first feature which is message broadcasting message broadcasting with pubsub this is really like the most basic functionality that any chat app offers if not everybody in the room can see new messages like really not a chat app at all so we're gonna start by taking a look at what Live View provides us out-of-the-box and then discuss why and how to implement message broadcasting from Live View all right so we have a fresh out-of-the-box live view let's talk about how it enacts real-time updates for the single user represented by one live view process so live view will receive a message when a user submits a new chat message it will update its own state and it will re render its own LED X template we need to understand that this happens within the live view process belonging to the user that submitted that message only and let's take a look at this from a UX point of view oh god that's no good so here is nice chat where I'm just casually talking about my dog's thoughts and feelings and we can see that the new message showed up for me and there's nothing here for the person that I'm chatting with so we definitely need message broadcasting this is no good in other words we need that sub this is the first point when I was building out this chat app that I kind of felt like I wanted to reach for phoenix channels but wouldn't it be nice if we could get our existing live view to simply broadcast updates to a set of subscribing clients shockingly we can use pub/sub to do exactly that just a note on what pub/sub is it's loosely described as a pattern in which you can publish messages to a top so that those messages can be consumed by any client subscribing to that topic and I also want to note that Phoenix's pub/sub library takes advantage of distributed elixir so clients across distributed nodes of our app can subscribe to a share topic and broadcast to that share topic because pub/sub can directly exchange notifications between servers when configured to use the PG 2 adapter which will take a brief look at a little later on one gotcha and I finally realized what was wrong with a live view feature that my team has in production this morning when I was reading this slide you need to remember to configure the distributed nodes of your app to allow for communication between those nodes over whatever range of ports pub/sub wants to use so if like me you are totally stumped as to why pub/sub seems to work sometimes in your production application remember alright so how will we use pub/sub to make sure that all of the users in a given chatroom can see any new messages i want to break down the procedure that we're gonna build out so when a live view process starts up for a given user we will subscribe it to that chat rooms topic then when a user submits a new chat message that live view will broadcast to all the other chatroom subscribers which are all the users in the chat room the subscribers will receive the message and they will act to update their own live view processes state which will cause their own templates to re-render in this way we are going to combine the real-time capability provided by Live View with the ability to pass messages across a distributed set of clients provided by pub/sub a pretty powerful combination if you ask me I want to start just by taking a brief look at our apps pub/sub configuration so you get this out of the box when you start a new Phoenix app you don't have to write this configure self but we can see that our apps endpoint is configured with the Phoenix pub sub PG to adapter that way we'll be able to subscribe clients across the distributed nodes of our application should we deploy it that way and this configuration will ensure that the pub sub back-end starts up with our app and exposes its functions via our apps endpoint module alright so I think we're ready to teach our clients to subscribe to a shared topic in the live view when should a live view start subscribing to a chat rooms topic really as soon as the process starts up so we'll use the live view mount function to hook into this moment in time here's a simplified look at our mount function we're subscribing to the chatroom topic which we've decided will be chat : chat ID via the Phoenix pub sub subscribed three function which again we have access to via our ops and point module and now our live view processes will be subscribed to the chatroom topic as soon as the live view mounts and we're ready to start broadcasting all right broadcasting to a topic so when should a given live view process broadcast a message for our feature in our case it's as soon as a user submits that new chat message so we're going to use live views handle event callback to hook into this moment in time simplified look at our handle event function when a user submits a new chat a message live view will call handle event three here what we're doing is we're updating the chat with a new message record and then we're broadcasting this event to the chat room topic using the broadcast 3 function all of the subscribing clients all the other live views that are subscribed to this topic will receive this message along with the payload describing the updated chat via a handle and no function which we'll look at now here's our handle info - and it's going to match an an event type of new message it's going to receive the payload describing the updated chat all of these subscribers will update their own state via the assign function which will cause their own templates to re-render and everybody will see that new message append it to the page just a little overview with this extremely beautiful color-coordinated chart that I am extremely proud of so in step one our user will submit a new chat message in step two that users Live View process will update the chat and broadcast a message to all the subscribing clients in step three all of these subscribers will consume that broadcast step four they'll update their own state and causing the template to re-render pretty cool so what did this approach win us the Phoenix pub sub library allowed us to build a real-time feature that broadcast shared updates to a set of users with just really a few additional lines of code like maybe six lines of code it's pretty cool our Phoenix app was already configured to use pub/sub it already had the pub/sub back-end up and run and so integrating it with our existing live view code was really pretty straightforward and we had even more advanced real-time functionality up and running in no time which brings us to our next feature now that our live view is smart enough to broadcast messages to all the users who are in the given chatroom I think we're ready to build a feature that actually tracks those users so let's say we want our template to render a list of people who are in the chat room something like that in this handsome purple box we could there's options here right we could create our own data structure for tracking user presence and a live view store it in the live view socket hand roll some function may be leveraging like an agent or something to share this information across clients build all our own functions to update that data structure when a user joins leaves or otherwise changes state and then we could use pub/sub ourselves to broadcast these changes that sounds like a lot of work and I really don't want to do it it also sounds like exactly what Phoenix presents does so the Phoenix presents behavior abstracts this work away from us it provides presents tracking for processes leveraging pub/sub behind the scenes to broadcast updates and it's also I think interesting to know that eases a CR DT which stands for am I going to get this right conflict-free replicated data type model which means that it works with distributed applications pretty perfect so unlike pubs uh you do have to configure presents yourself in your own application so let's take a look at what that looks like now we'll define a module called chat web presence it uses the presence behavior and it specifies that it shares a pub sub server with the rest of the application now we can use the chat web presence module throughout our app to track user presence in a given pub subtopic and events that are broadcasted by presence will get broadcasted over our same pub sub server so other processes in our app can subscribe to it our presence module will maintain lists of present users in a given chatroom by storing these users under our chat room topic once again in this case chat : chat ID so we've got present setup we know roughly the functionality that we're going for I think the question to ask ourselves now is when should we tell presents to start can you give an user and I think we can answer that question with a question which is at what point in time do we consider a user to be present in a chat room and again it's when the user mounts the live view so we'll continue to hook into our mount function again simplified just showing the relevant code well look into our live views mount to function to add the new user to presences list of users in a given chatroom we're using the presence track for function to track our live view process as a presence we're adding the pid' of the live view process to presences datastore along with a payload describing the new user under our shared topic of chat : chat ID and a key of the users ID and having started to track this presence presences process the presents processes it's kind of a tongue twister the presence processes State for the given topic will look something like this so we could got our user ID and then the metadata describing the users in this case email and how can we ensure that the other live view processes representing users in the chatroom become aware of the new user drawing though it's great that we've added this user to presents datastore but the whole point is like everybody knows it and sees the users who are in the room so when a user is tracked by presence via that call to presence track for presence will first update the list of users for the given topic and then it's gonna broadcast a presence diff event recall that all of our Live View processes use pub/sub to subscribe to the chatroom topic on Mount since presence is tracking users under that same topic and sharing a pub sub server with the rest of our app our subscribing live view processes will receive this presence diff broadcast from present so we can use the handling of this event to have each subscriber grab the latest list of users and render them on the template let's teach our live view how to handle that presence diffident we'll define another handle info to function in our live view this time it'll listen for the event of a type of presence diff our function needs to get the list of present users from the presence data store and add them to the live view socket states that the template can re render and reflect any newly joined users so let's take a look at how we can fetch these users from presents will use the presents list one function to retrieve a list of tracked presences and their metadata for our topic and then we're just going to iterate over that metadata pull out the list of usernames lastly we need to update live view sockets date with this list which we do via socket assigns we're adding a key of users with a value of this list of usernames and calling a sign triggers the live views render function so the template will rerender this time with all of the users including any newly joined users that triggered this presents diffident so let's take a look at the template code to render those users now pretty straightforward having added a key of users to our live view socket signs we can access our list of users via the at users assignment and in the led X template and we can just iterate over them render their first names pretty simple stuff but wait let's think about this for a second the code we have so far will broadcast an event whenever a new user joins the chatroom that will cause all the subscribing live views to grab the list of users from presents and render them so what we've really described is people already in a chat room having to wait for a new user to join before any users are displayed that's not a great feature I think to offer our users and our very fancy and sophisticated chatroom app so how can we display a list of present users as soon as someone joins they should see that list when the template first renders for them we need to be able to fetch presents for those new users who are joining and once again we're going to hook into that mount function of our live you to make sure that that happens so in our mount function we will also use presents lists to grab the list of users get their user names from that metadata and add them to socket assigns here so that they will see they will see the list of users on the page as soon as it renders for them pretty great so we've talked about a user joining and ensuring that everybody who's already present will see their list of users on the page update and reflect a newly joined we talked about ensuring that users who do join will see a list of people who are already there as soon as the template renders for them for the first time the only thing we have left to discuss is what happens when a user leaves the chatroom how can the update present State and broadcast changes when a user pieces out from the chat so recall that we're tracking presents for a given live view process via the presents track for function where the first argument that we give to track four is the pidove the live view process what happens to a live view process when the user navigates away from the chat show page she asked rhetorically it dies the live view process terminates as I'm sure many of you guessed this will cause the presents untracked three function to get called thereby untracked Ehrman ated pin which will in turn tell presents to remove the list of users from that user from the list of users for the chatroom topic and once again for free it will broadcast the presents dip event for you subscribing live view processes representing users who are still in the chat room already know how to handle that presents diffident they're gonna fetch the list of users from the presents datastore that list will no longer include the departed user they'll update their own socket assigns and the template will rerender without the person that left pretty cool so in other words in order to handle what happens when a user leaves you have to do exactly nothing which is often I love having to do nothing all right so before we move on I just want to briefly touch on some of the other things that this powerful combination of presence and live you can do freedom now that presence is fully integrated with our live view you could really imagine using it to do a lot more than just tracking whether or not a user is present you can use it to do things with the state of that given user so in our chat app we could do things like allow a user to set their status to away put some information on there about how long a use an either has been active or inactive for indicate whether or not a certain user is typing and so much more so any such features would seamlessly integrate into our live view thanks to live view and presences shared pub/sub server and topic so live you pub/sub and presents all play together really nicely and before we move on to the very last piece of our roadmap for today I just want to take a step back and recap what we've built so far so with our out-of-the-box live view our chat has the ability to push real-time updates to only the user that initiated that change so in other words users who submit a new message via the chat forum would see that new message appear and nobody else would but with the addition of pub/sub we were able to broadcast these new chat messages to all of the Live View clients subscribe to a given chat rooms topic everybody in the chat room and then by leveraging presence we were able to track and display the list of users present in a given chat room at any time so the flexibility of pub/sub made it really easy to subscribe all of our running Live View processes to the same topic on the same pub/sub server an edition presents modules ability to share that pub/sub server with the rest of our app allowed presents to broadcast events to those same living processes so overall Live View pub/sub and presents really get along and they've enabled us to build a really robust set of features with very little hand-rolled code which I don't know we're all probably pretty lazy I'm a fan okay so this brings us to the last topic on today's road back live view and JavaScript interoperability by the way I've been really paranoid that I'm gonna mispronounce interoperability cuz it's kind of a tongue twister so far I've nailed it three times but there are more opportunities for me messes up okay so Live View and J's Interop happens via a feature called life you hooks and we're gonna dive into this last topic via the last of the three features our chat app needs to implement which is a responsive UI before we actually talk about this feature and how to implement it I want to describe a problem that we have look ok you guys looks terrible and the current state of a world when a new chat message is appended to the chat window it appears just out of frame this is a really terrible user experience and even for someone like myself that doesn't spend a lot of time on the front end I know that this is not OK and no respectable p.m. would like allow you to get this out the door the chat window needs to scroll down to accommodate and display new messages keep talking there we go nope cool fingers crossed this is easy enough to do with just one or two lines of JavaScript like even I know this you would grab the height of the chat window and you would set the scroll top accordingly what you really want to do especially if you're familiar with phoenix channels you're gonna find yourself reaching for something like this you wish you could write just a little bit of code on the front end that listens for the arrival of those new chat messages grabs the chat window and adjust the scroll tab that's what you want to do you can't kind of you kind of can and I'm gonna talk a little bit about I'm gonna talk a little bit about what you used to have to do to get something like this working up until very very recently so before the official release of live view which I think came out at oh three oh I'm not sure responding to a custom Live View event on the front end was really not easy the live view JavaScript offering did not expose a way for us to hook into specific DIF events on the front end all those dips are calculated on the back end which is one of the other awesome things about Live View you have that nice dipping engine and the server-side rendered HTML but then down to the front and it would really just push out a diff event and you couldn't really do much with that so the first version of this presentation that some of you may have seen at elixir conf was created in that world before the release of o3o and its introduction of live UJS intro that left me writing a lot of really complicated weird code it was fun though so in my original workaround which i just want to touch briefly on because I enjoyed it before I show you the easy way to do this basically I slide it up so that each live you process got its own accompanying like side car channel and I had the client join that channel over the same live view socket when live you first rendered the template later when a user submitted a new chat message I had the live view process send a message to its accompanying channel which would in turn push a message down the socket to the client so that we could fire just that little snippet of squirrel top adjust javascript and in order to get that working i hijack the live you socket source code i augmented it with a custom channel I had this whole complicated channel registry so that the live view could look up the pin of its associated Channel all of that so that I could basically just write this one line of scroll top equals scroll hate it was cool it was actually really terrible and complicated and as I was building the presentation the first time I just thought like I can't recommend that anyone ever do this it's it's way too much work and the good news is you don't ever have to do it so wouldn't it be great if we could hook into live view events on the front end after all we already saw by peeking at some source code live view is just a channel and channels do send events to the client so introducing thank you Chris McCoy at all live you hooks what are they so life you books are the interface for live view and JavaScript Interop not even gonna try and drop anything it leverages JavaScript lifecycle callbacks to fire custom js4 particular live view events and the events that we can hook into now are when an element is added removed or updated by the server this is a full list of all of the events that you can hook into with live view hooks but for our particular feature our responsive UI for new chat messages we really just care about the updated event when the element has been updated in the dom by the server in this case when our chat window has been updated server-side by the addition of a new message so by hooking into these callbacks Live View hooks allow you to do two things you can fire a custom j/s which is what we want we want to adjust the scroll top of our window and you can also manually push events back up to the Live View process on the server we're not gonna be having much of a need to do that today but you can which is pretty cool alright so how does it work pretty simple setup all you have to do is add a Phoenix hook binding to your dom element in which case the chat window whose scroll top we want to adjust here it is here's the messages chat window we're adding this Phoenix hook that I've called new chat message so now we have to go ahead and actually define the new chat message hook defining the hook object we our establishing our hooks object which is an empty object adding a new hook new chat message next up we need to actually add that lifecycle callback in our case we want our new chat message hook to invoke the updated callback when the given Dom element is updated by live view so what can our callback do what kind of stuff can we do within this updated callback function a couple things the hook callback function exposes a handful of attributes that are in scope for you you have the element the actual bound Dom node you have the view name which has that Dom nodes Phoenix view value and then you also have access to this push event function which is how you can push back up to the live view server-side we really are just going to leverage the l the element are bound Dom node attribute today so when our chat window is updated in the Dom are updated callback will fire and it's going to execute our scroll top adjustment code which looks exactly like this pretty simple pretty cool pretty easy to use the very last thing we need to do to get this all working is make sure that we pass our hook object to the socket so we need to add this payload when we establish our live view socket before we connect we pass in our hooks and that's it all right so let's review what's gonna happen a user will submit a new chat message live you will receive that message and broadcast it to the subscribing clients the subscribing live views will consume that broadcast they will update their own state via socket assigns and re-render their templates the new chat message hook will fire the updated callback function will be invoked and it will set our new scroll top and we're done that's it it just works which is awesome alright so one more peek under the hood it's in live view source code before we wrap up once again reminder don't let my dog under the hood of your car alright so hooks under the hood the code underlying the hooks functionality has three basic parts we're gonna establish any hooks passed into our live view socket initialization via the live view constructor function we're gonna add any hooks to the Dom elements to which they're bound via that Phoenix hook binding and lastly we trigger the hook callback functions under the appropriate conditions all right establishing hooks in the constructor super super simplified look at live views live socket constructor function we can see that this dot hooks is set to the hooks object that we passed into our live view sockets initialization so later the hook callback functions we defined are mapped to the Dom elements that define Phoenix hook bindings again very very simplified version we see that what's happening here is that we're looking up the Phoenix hook on the Dom element if there are any it's creating a new view hook instance that we can trigger the hooks callback so that we can trigger the hooks call back later under the right conditions so the hook callback functions are invoked when a corresponding live view event is pushed down to the front end client when Phoenix live view invokes the update function upon receiving an update from the server it's gonna call the trigger hooks function which I want to take a brief look at now again very simplified but essentially look up the hook for the given changed element and trigger the updated callback function and last thing I think I think it's the last thing taking a look at view hooks trigger function the trigger function simply looks up the callback function from that particular hook object and invokes it it's pretty cool it's easy to use even if you're like me and writing a lot of JavaScript is not your thing it was pretty nice to be able to take a look under the hood and sort of see how all the pieces fit together okay let's recap we did it my dog again he's really happy for us we did a lot of things so by integrating pub/sub presents and hooks directly into our live view we were able to support message Broadcasting user tracking and a responsive UI all of the features that support a rich real-time chat experience so really live view it can do it all the seeming limits that live view presented us when we were building out our chat application we got over them we got through them by incorporating available Phoenix real time tools almost all of our chat functionality that we took a look at here is handled and less 100 lines of life and code and this is as opposed to all the channel back in front end code that you would otherwise write again if you think back to the first couple of slides of source code that we looked at for Phoenix live view that stuff that we were all having to write to set up our own channel implementation we don't have to do that anymore so using pub/sub to do what pub/sub is meant to do which is broadcast and subscribe it really doesn't feel like a misuse of Live View it feels like it fits together really nicely and layering presents on top of that functionality also feels like a really good fit and lastly the recent introduction of Live View hooks makes it super easy to implement any custom Jas when you absolutely absolutely need to write your own JavaScript that's it thank you [Applause] yeah well you hear me oh okay thanks again so we have time okay um do we have any questions okay we still want to have a mic for uh recording one of the one of the things that jumped out I hadn't seen the the new hooks API but it's suspicious to me that they would include a push event function so you could just like hey something updated in the Dom do you want to let the server know I'm sure there are cases where that would that would make sense but I couldn't think of any and it would seem to beg a sort of like loop or a sort of like event soup and I'm curious have you run into any any use cases where you actually needed to push an event after a dhama date yeah that's a great question so I was actually thinking the same thing I feel like you could get stuck in almost like a recursion problem not quite recursion but yeah this infinite loop of like all right so let's say somebody clicked a button I sent an event to the server server side updates I trigger an update callback I push an event it could be easy they play that a little bit wrong and then have that event trigger an update and push an event forever which would be terrible yeah I can't really think of a feature that would cause me to reach for that push event maybe let's say something on the front end needs to update in response to a server-side event but like conditionally maybe based on some other features on the page conditionally pushing something back up yeah so to answer your question I have not reached for push event myself and if anybody else has or can think of a good reason to I'm certainly all yours thank you vism if you have like geolocation or some kind of sensor type of thing on a browser that you want to push back maybe I'm sorry any more questions okay thanks Sophie I forgot sorry I forgot one shoutout which is these illustrations were provided by Miss Penny Wong [Applause]

Channel: The Big Elixir

Views: 1,892

Rating: 4.8947368 out of 5

Keywords: Elixir, Erlang, Pubsub, Functional Programming, LiveView

Id: yo8Y1SUGW1w

Length: 39min 23sec (2363 seconds)

Published: Mon Dec 02 2019