Netflix JavaScript Talks - RxJS + Redux + React = Amazing!
HTML-код
- Опубликовано: 14 сен 2016
- Jay Phelps (@_jayphelps ) talks about why Netflix loves reactive programming with Rx. In this talk he shares the basics of RxJS 5 Observables and how they can be used with React and Redux to manage asynchronous effects using redux-observable.
redux-observable.js.org
Slides: www.slideshare.net/jayphelps/r... 
Наука
{ ToDo: "FIX_AUDIO" }
LOL!! XD { Type: YesPlease }
@@RockstahRolln audio need noise-cancelling 😂
I muted the video and lip read the talk.
Better to use standard actions.
{
"type": "ADD_TODO",
"payload": {
"title": "Fix Audio"
}
}
I love nothing more than someone interrupting a speaker in the middle of their talk...
Really good introduction - despite the recording quality, will definitely give both RxJS and redux-observable a look.
And this is why watching RUclips in bed at 2:30 AM is not always a bad idea.
Great talk. Looking forward to trying it out at work tomorrow.
mistenktdotcom lmao its 2:45am here atm why i read this comment..
2:51 and still it seems super cool
2:43 AM
4:30 am
@@toxico2699 Get some sleep
These talks are all very well done but whoever was in charge of audio should try a little harder next time.
React Router talk has a horrible audio :(
Thanks for your comment. I just thought my laptop speaker is time to get replaced. :)
This is the third netflix presentation that sounds this awful - maybe it's some loser relative of Reed Hastings, who they can't fire.
Skip the first 15 minutes then it's worth it.
Just download it and play it with other players.
This is so clear and makes the whole picture clear.
really great talk. it explains well the concept of redux and adds rxjs part in a very clear way. Thanks, even now in 2020, it is still a great presentation.
Brilliant talk! And special thanks for non-trivial examples!
Very very very good talk ! It is worth it to watch it despite the (bad) sound quality.
Thanks a lot for the talk, I enjoyed and I'm going to learn RxJS right now :)
Nice talk!, Definitely I am giving redux-observable a try.
I've been using redux-observable in my current project and I just love it! It was hard to grasp the RxJS stuff at first, though.
Thanks for the great talk! This really helps me understand redux-observable.
I live in Karachi Pakistan I like your comments send 4 month ago
very very useful presentation, it is very much helpful to relate all the concepts of redux especially for those who have started their career in react technologies.
really awesome talk
NICE!! Going to learn RxJS this weekend.
Really good talk!
Great presentation about rxjs.
Excellent presentation
And "three ducks" is hilarious, finally managed to recognize those on the logo : )
very informative talk, thank you
Thanks for this talk. It is informative to me.
awesome talk. RxJS + Redux....looks great. 20:09 (logo rocks!)
Nice talk!
giving it a try right now.
it very nice attempt with good explanation thanks ...
Great lecture
My guess on the audio: Probably was a talk given internally, and someone recorded it and posted it on their own as an after-thought.
I have stumbled with a new project that handles connections and redux with this library, and yes, it still looks like rocket science in 2022.
great talk (ohuenno), using it in one of our apps
Thank You, very interesting!
that was EPIC!
Rx is one of the most difficult libraries I've ever tried learning, the combination of FRP concepts + an extremely large API surface area. Debugging is difficult, the documentation is difficult for beginners. Worth it though. Keep at it if you feel the same.
Very true, but good things generally aren't easy. Rx is definitely a huge step in the right direction for web tech.
What? Rx is incredible easy. It's basically just an observer/observable composition, at which you throw a few event handlers.
Just because you think it's easy doesn't make it easy. Especially for programmers coming from OOO background. RxJs is definitely a step in the right direction, and it produces some excellent work. However I also found debugging to be difficult. You have to resort basically to .tap/.do statements and the good old fashioned console.log
OOO background you say
Good things "are" easy, simplified, and well structured. e.g iphone
I can use es6 async/await with promise and es6 destructuring to make code looks like sync, but in redux-observable how to use it with async/await and destructuring together?
Nice talk
Great sound.
awesome!
Great talk! Seems to be solving all async actions related problems we are facing with redux.
If only there was an easy way to sell RxJS to my colleagues 😕
Good luck with that. It drives me crazy!
Provide a good use case example. Or even better, a problem which would be a nightmare to solve just using promises, and show them a possible solution using Observables and you won't have to sell it.
So, question: does reactjs implements hooks for using redux under an observable context?
I understood the need for canceling the request when I started building my first react native app. API timeout alert started to appear one above the other.Since then I've been using abort controllers to cancel the api requests in every app.
Middleware is something that sits between and doesn't work in parallel . I believe website of redux-observable states that actions hit the reducers first and then dispatches another action. So calling it a middleware in talks and writing on your site might be a whole lot confusing.
Is someone share any resource for this promises trick @8.40, I'm trying to understand it
I would say, the talk 3 years ago makes me more clear about NGRX...
I'm sure it was clear to most everyone, but an addition to the concept of a "pure function" is that it also modifies nothing outside of the function. I.e.
let count = 0
const sum = (x, y) => { count++; return x + y }
Same input always gives the same output, but it's not pure.
Yeah, he said that
That is what he is calling a side-effect.
Jeez guys, be thankful for them posting this video and don't just slam the audio quality.
if my video had a problem, i would want to know so that the problem is fixed. that's how to world works. we can be thankful and give criticism at the same time.
criticism =/= annoying pathetic pretentious child repeating the same obvious thing in an emotional way to sound smart on the internet
Sorry, but I can't listen this. So video not helpful for me. Thanks for sharing but it useless.
We ARE Greatful! But try listening to this through your earphones... Make sure you have your ENT's number on hand
Yup , the talk is indeed helpful. But it's Netflix and people have expectations about the audio/video quality.
30:24 the bold guy giving a thumbs up
wow nice, NGRX is like this type.
Awesome,great job ! I follow
FYI..ECMA proposal for observable (cancellable promises) was withdrawn..
Pretty neat ideas going into redux-observables. I definitely never consider the case of needing to cancel a pending ajax request, so that probably means there are a bunch of unencountered bugs in my deployed code O.o I don't think I'll abandon my GraphQL setup for this, but maybe in my next React project I might give this a try.
Alex Leung agreed 😔
I implemented this and was very excited about it 🙃but then after trying to inject it in the "new" configureStore from RTK; it didn't work as I'd expect (maybe I implemented it wrong) and after reading and reading, trying and trying... I saw that the project has been left abandoned since some time ago already and now exists something called thunks 🤣😿.
The good thing is that if you are able to implement ReduxObservable in your project; thunks will be a piece of cake.
Thank you Netflix UI "Engin-earing".
The hash/link for this youtube video begins with `Aslncy`
One minute into the video and I’m wondering what about middleware?
Is this to do with me getting wierd thumbnails for youtube videos?
thanks
The audio is unbearable with my headphones. Luckily the subtitles work.
Great
For what was describe as the problem you can use redux thunk
you could use promises and still have a "callback hell". That indentation example that everyone uses should not be listed first as one of the main reason to use promises instead of callbacks. It just drives the focus to the code quality instead of the real security and composition problems that are present when using callbacks.
if you have callback hell with promises, you aren't using promises to their full potential. Instead of this `somePromise().then(function(...) { anotherPromise().then(function(...) { }) })`, you can do `somePromise().then(function(...) { return anotherPromise() }).then....`
i miss the ocean, and sandy beaches
🔥🔥🔥
What are the advantages of using rxjs over redux-thunk for async operations?
RxJS really shines when you're dealing with dispatching actions from UI events, it makes really easy to reason about because UI interactions are data streams and RxJS does have a lot of ways to handle those.
You can do that with thunks too, but thunks are promises hooked to redux, and promises are very straightforward and easy to understand when you're triggering them once. When you're trying to handle event streams it gets really hard to manage what you would do with rxjs observables in just few lines of code
Second time watching this.
1️⃣st time (familiar with Redux only), "It looks cool but what am I looking at here???"
2️⃣nd time (after 2 days of learning RxJS): "Wow... I am able to see something now"...
Let me come back in few weeks to see if I dig it completely. :)
@nabil libre no
Did you give up on ReactiveX? 😂
@@thatoneuser8600 Yes. I have. But at least I know when to make use of it :)
@29:06 shouldn't action be called value in the ...switchMap(action => ajax("..." + value).map()... ) statement? - otherwise i don't get it.
Yep, typo. Something like ajax('...' + action.payload)
Netflix can make their own amazing TV shows but cant seem to film (or record audio) better than a high school student. FAIL!!!!!
Raymond Martin your an idiot. this is Netflix. and they can't sort out a simple single channel audio setup that a teenage RUclipsr in their parents basement can easily pull off.
this is actually so bad it hinders the msg. if you think otherwise YOU are watching these "wrong"
Raymond Martin ok there high and mighty. You are the one who is implying you can watch a video "wrong".
You sir are an idiot, and that's a label not a name.
Well, they probably farm out all those shows to separate production companies, having no audio or video engineers on staff. That said, showing video on the internet is their bread and butter, so they should certainly for the sake of their reputation at least apply themselves even on side projects like this.
you're*
what's with these autist circlejerking 10 year olds? lol i doubt they actually learnt anything from the video, too busy being triggered and a bunch of sad pretentious twats in the comments
Great! I love the architecture. But where did the name EPIC come from?! It doesn't say anything. It's not self-explaining. It could be simply called "mapper", and our lives would be simpler ;)
I've been watching videos about react for the past week.. There weren't a single one where I didn't heard "ThreeDucks" instead of "Redux". Damn it... hahahahahaha
cool~
Hello ! :D Is RxJS popular in Korea ? :O I saw it even has the documentation translated in korean on the official RxJs site.
Sound good but!!! it does not convince me to change or implement it in my projects. So I continue with old one.
hmmm, why not RxDux or RxDucks?
Why not mobX?
Redux saga do the same things right ?
yes
I wonder if he can say denounce one more time....
Someone keeps stepping on my bottles.
8:47 uhh, "some people don't know". I'm pretty sure Promises were intended to be used that way. Returning a promise from a .then callback is the core of promises.
Doesn't mean that everyone knows it
Correction: Default Promises cannot be cancelled.
There are other implementations, like Bluebird Promises - they can be delayed, timeouted and, oh wait, Cancelled.
Still single value
OmegaMindriel Louth MRI yuy jutrtyyyehrwyli
You'd like Go channels, like this but less hacky, and Redux is super over complicated. CSP in JS would be nice for this sort of thing.
are you saying there should be more generator usage in front-end JS?
Yep, I don't think JS has quite enough defined there to unify things, but typically this sort of thing would just be pipelining coroutines. Lua's implementation is definitely a good example too, but it would stop us from having to define these APIs at the library level.
doesn't CSP and Goroutines introduce some new forms of race conditions in JS via generators?
Clojurescript?
I think it's clear that RxJS can reduce the lines of production code we need to write in complicated, async cases. What I'm still not convinced of (and this talk completely skips over) is how to effectively unit test all this behavior.
RxJS lets us compose complicated behaviors using the various Observable operators (switchMap, debounce, takeUntil, etc), and at the end of the day, we still need to verify that we've composed these behaviors correctly.
Is there a good unit-testing story for these complicated epics? What would a unit-test suite look like for the autocomplete example mentioned in this talk? What about the multiplexed, bilateral web sockets example?
It would be even cooler to compare the unit tests between the traditional callback/Promise based implementation with Observables. Is the testing code also simpler, more succinct?
Thanks, really is a great video!
I am not realy sure how to test multiplexed or bilateral senarios, but I do believe observables simply return an array of data over time. So basically when unit testing, we would construct an array of mock data and pass it to the component. and expect the result. Though, I am still not sure how to unit test the request cancel senarios
Just use redux-saga. Easy to read and works like a charm. No callback bullshit.
video quality like camrip of 2007 year
The audio quality could be better. And the focus of the camera too
Isn't he just describing using finite state machines? Can't one just use a finite state machine instead of all of these tools? What am I missing?
You're missing composability and asynchronicity. Basically, this acts more like the actor model than a finite state machine. You don't need all of those tools if you can write actor models, though, that's true.
Mostly, though, it's a matter of taking what people use and building on it, versus trying to learn people new things. Also, finite state machines and actor models produce very subtle bugs, they take the load off by maintaining this for you, so you don't have to worry about those bugs.
I think this is actually the "observer pattern", isn't it? I thought reactive programming in general was a formulation of the observer pattern. Although I suppose the observer pattern could be thought of as a specific implementation of the actor model.
Anyway, you're totally right about the subtle bugs. There are a few aspects of rxjs (although not redux) that I find useful for the work I do and simplify the thinking behind some of the components I create. I'm still not sure why a project would need both, but rxjs is an interesting state management library in cases where the logic is too complicated for a basic state machine of some kind.
Hé ouais c'est une très bonne explication. Néanmoins le point négatif de tout ça c'est que toutes les grosses entreprises de la mondialisation se sont emparées des technologies. Ok elles en ont fait quelque chose de bien organisé et de pratique à utiliser. Mais mince alors rien que cette vidéo est délivrée par Netflix.
I didn’t follow how this fits with synchronous Redux.
It's been 6 years still Observables are not standardised in Javascript lol.
Netflix is shit, the sound keeps going out of sync with the video, maybe you should have them in the same stream!!!
At, ruclips.net/video/Yy7gFgETp0o/видео.html
" The problem with this syntax is that a different callback is created each time the handleTabClick renders. In most cases, this is fine. However, if this callback is passed as a prop to lower components, those components might do an extra re-rendering." React Documentation.
So i think this patterns should be avoid.
Geat talk.
"... don't Rx all the things".... Don't tell me how to live my life.... Haha.
This was a bit hand wavey. "Doing async in RxJS is easy!" * shows a delay function * "It makes your code really easy to write" * shows an unreadable slide assumedly containing socket code * "any questions?"
The slide was actually readable
What? You think you will learn 100% of RxJS and redux-observable in a single 30 minute video? Haha. Not to mention, he did show a pretty complex problem with the websockets example. Anyway, when you build something better and do a better video in 30 minutes or less, let me know.
That websocket slide was readable, valid and my god was it amazing! The talk was great, but that one slide blew me away. As someone who works with websockets all the time that was an incredible improvement of the workflow.
Websocket code on screen
const socket = WebSocketSubject.create("ws://stock/endpoint")
const stockPickerEpic = (action$, store) =>
action$.ofType('START_TICKER_STREAM')
.mergeMap(action =>
socket.multiplex(
() => ({sub: action.ticker}),
() => ({unsub: action.ticker}),
msg => msg.ticker === action.ticker
)
.retryWhen(
err => window.navigator.onLine ?
Observable.timer(1000) :
Observable.fromEvent(window, 'online')
)
.takeUntil(
action$.ofType('CLOSE_TICKER_STREAM')
.filter(closeAction => closeAction.ticker=== action.ticker)
)
.map(tick => ({type: 'TICKER_TICK', tick}))
);
Redux Saga anyone ?
Redux Epic?
I see a battle over here that should start.
isnt the point of this to replace sagas?
Is the intended audience really so unfamiliar with Promises that they don't know they can be chained...?
Computer science changed the whole hanity diecyion
Your ears will start bleeding from 00:02 until the very end.
Managing state stuff is not hard. Redux and React Native simply make it so difficult to follow state management under the guise of "simplification" that code become excessively obfuscated, difficult to read and follow and manage when things break. Introducing new developers to the code, independent of their experience with React Native is more overhead than any other system we have used. I am still unconvinced by React Native.
People should remember that Visual Basic has been doing what's touted here since the 90s...
aka NgRx
sadly song recording is bad...
your spinning logo is triggering the laptop fan...
"an reducer" ?
fuck
Sometimes I think React is a front for these endless tools "we must have". Ah the good ole days of HTML and plain JavaScript are sometimes missed.
It reminds me of Java's good 'ol RMI except this time people are embracing it for some reason.
And there's the whole learning curve:
_You also realize that while before you were able to do:_
_$(“.my-button”).click();_
_to get a button to do something; it has now been about 3 hours and your one button doesn’t do anything._
- hackernoon.com/thinking-in-redux-when-all-youve-known-is-mvc-c78a74d35133
Then came Reaxt Query 😂😂