it-ebooks - Rxjs 5 ultimate
Here you can read online it-ebooks - Rxjs 5 ultimate full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2018, publisher: iBooker it-ebooks, genre: Romance novel. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
- Book:Rxjs 5 ultimate
- Author:
- Publisher:iBooker it-ebooks
- Genre:
- Year:2018
- Rating:3 / 5
- Favourites:Add to favourites
- Your mark:
Rxjs 5 ultimate: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Rxjs 5 ultimate" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
it-ebooks: author's other books
Who wrote Rxjs 5 ultimate? Find out the surname, the name of the author of the book and a list of all author's works by series.
Rxjs 5 ultimate — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Rxjs 5 ultimate" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
- Starting out
- 1.1
- 1.2
- 1.3
- 1.4
- 1.5
- Observables
- 2.1
- 2.2
- 2.3
- 2.4
- 2.5
- 2.6
- Operators
- 3.1
- 3.2
- 3.3
- 3.4
- 3.5
- 3.6
- 3.7
- 3.8
- 3.9
- 3.10
- 3.11
- Recipes
- 4.1
- 4.2
- 4.3
- 4.4
- Advanced
- 5.1
- 5.2
- Appendices
- 6.1
- 6.2
- 6.3
To truly understand Rxjs I recommend trying to implement a subset of it yourself just to see what kind of code you produce. For most cases it isn't really necessary to understand on that depth but do try it if you got some time over. Let's look at what a really basic implementation can look like and refactor it slowly into something that looks like the real thing.
A cascading call means that based on what call is happening another call should take place and possibly another one based on that.
A dependant call means the calls needs to happen in order. Call 2 must happen after Call 1 has returned. It might even be possible that Call2 needs be specified using data from Call 1.
Imagine you have the following scenario:
- A user needs to login first
- Then we can fetch their user details
- Then we can fetch their orders
login() .then(getUserDetails) .then(getOrdersByUser)let stream$ = Rx.Observable.of({ message : 'Logged in' }) .switchMap( result => { return Rx.Observable.of({ id: 1, name : 'user' }) }) .switchMap((user) => { return Rx.Observable.from( [ { id: 114, userId : 1 }, { id: 117, userId : 1 } ]) })stream$.subscribe((orders) => { console.log('Orders', orders);})// Array of ordersI've simplied this one a bit in the Rxjs example but imagine instead of
Rx.Observable.of()it does the proper ajax() call like in
- We can fetch a users details
- Then we can fetch Orders and Messages in parallell.
getUser() .then((user) => { return Promise.all( getOrders(), getMessages() ) })let stream$ = Rx.Observable.of({ id : 1, name : 'User' })stream.switchMap((user) => { return Rx.Observable.forkJoin( Rx.Observable.from([{ id : 114, user: 1}, { id : 115, user: 1}], Rx.Observable.from([{ id : 200, user: 1}, { id : 201, user: 1}]) )})stream$.subscribe((result) => { console.log('Orders', result[0]); console.log('Messages', result[1]);})We are doing switchMap() instead of flatMap() so we can abandon an ajax call if necessary, this will make more sense in
Async code is code that isn't done immediately when being called.
setTimeout(() => { console.log('do stuff');}, 3000 )3s seconds in the future the timeout is done and do stuff is echoed to the screen. We can see that the anonymous function we provide is being triggered when time has passed. Now for another more revealing example:
doWork( () => { console.log('call me when done');})function doWork(cb){ setTimeout( () => { cb(); }, 3000)}Other example of callback code are events here demonstrated by a jQuery example
input.on('click', () => {})The gist of callbacks and async in general is that one or more methods are invoked sometime in the future, unknown when.
So we established a callback can be a timer, ajax code or even an event but what is the problem with all that?
One word Readability
Imagine doing the following code
syncCode() // emit 1syncCode2() // emit 2asyncCode() // emit 3syncCode4() // emit 4The output could very well be
1,2,4,3Because the async method may take a long time to finish. There is really no way of knowing by looking at it when something finish. The problem is if we care about order so that we get 1,2,3,4
We might resort to a callback making it look like
syncCode()syncCode()2asyncCode(()= > { syncCode4()})At this point it is readable, somewhat but imagine we have only async code then it might look like:
asyncCode(() => { asyncCode2(() => { asyncCode3() => { } })})Also known as callback hell, pause for effect :)
For that reason promises started to exist so we got code looking like
getData() .then(getMoreData) .then(getEvenMoreData)This is great for Request/Response patterns but for more advanced async scenarios I dare say only Rxjs fits the bill.
There are two major approaches how to handle errors in streams. You can retry your stream and how it eventually will work or you can take the error and transform it.
This approach makes sense when you believe the error is temporary for some reason. Usually shaky connections is a good candidate for this. With a shaky connection the endpoint might be there to answer like for example every 5th time you try. Point is the first time you try it might fail, but retrying x times, with a certain time between attempts, will lead to the endpoint finally answering.
The retry() operator lets us retry the whole stream, value for value x number of times having a signature like this :
retry([times])The important thing to note with the retry() operator is that it delays when the error callback is being called. Given the following code the error callback is being hit straight away:
let stream$ = Rx.Observable.of(1,2,3).map(value => { if(value > 2) { throw 'error' }});stream$.subscribe( data => console.log(data), err => console.log(err))The stream effectively dies when the error callback is being hit and this is where the rety() operator comes in. By appending it like so:
let stream$ = Rx.Observable.of(1,2,3).map(value => { if(value > 2) { throw 'error' }})retry(5)This will run the sequence of values 5 more times before finally giving up and hitting the error callback. However in this case, the way the code is written, it will just generate 1,2 five times. So our code isn't really utilizing the operator to its fullest potential. What you probably want is to be able to change something between attempts. Imagine your observable looked like this instead:
let urlsToHit$ = Rx.Observable.of(url, url2,url3);In this its clearly so that an endpoint might have answered badly or not at all on your first attempt and it makes sense to retry them x number of times.
However in the case of ajax calls, and imagining our business case is shaky connections it makes no sense to do the retry immediately so we have to look elsewhere for a better operator, we need to look to
Font size:
Interval:
Bookmark:
Similar books «Rxjs 5 ultimate»
Look at similar books to Rxjs 5 ultimate. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Rxjs 5 ultimate and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.