Code samples of angular data in action.

[Jafar Husain]

Hey guys,

I am on the TC 39 (JavaScript standards committee) and I need some code examples of angular data in action. I have been asked to provide examples of how better language support for observable in JavaScript could make programming Data in MVC frameworks easier.

Any code snippets you can give me that you have written would be immensely useful.

J

[Jeffrey Cross]

Hey Jafar,

Does it need to be Angular 2 examples, or would examples of using AngularJS 1.x say with RxJS be useful?

--
You received this message because you are subscribed to the Google Groups "angular-data-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/CAOTbQj0WG79HyiY1XWN%3Dicyj6QLR2H8w-Km-BKjtEv68WPTaZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Jeff Cross

[Jafar Husain]

Ideally angular 2. Part of the compelling reason for adding support to the language is that MVC frameworks like angular and react are taking bets on it, and supporting it natively.

Patrick and I tried to use your HTTP library in an example, but it looks like it might be a little too early still. It's also using RX Observable, not victors new observable. 

It would be great if your HTTP stuff could make it into the angular code base before the end of the month when the meeting is. What are the chances of that happening? 

If I had event, HTTP, and animation support as Observables  I could put together a very impressive code sample that motivated language support. I'm meeting with Matias today and I'm cautiously optimistic that I will be able to get him to agree to use Observable in the animation framework instead of promises.  Then I could say that angular would not have any promise support and that would be a strong motivator for observable support in the language.

JH

[Benjamin Gruenbaum]

> I could put together a very impressive code sample that motivated language support

Mind saying what use case that example would cover? As I said earlier I'm doing a lecture on observables and I'm looking for examples that showcase their strength that are more advanced than an autocomplete :) 

> Then I could say that angular would not have any promise support and that would be a strong motivator for observable support in the language.

I'm definitely not a part of *that* camp. The language needs observables because they're a much nicer abstraction than event emitters and they solve a real problem developers deal with every day - promises are already there solving a different use case.

I know it's "not really my business" but I think any attempt to do *everything* (even things with one value that are already started and are cold and not lazy) with observables will give us the exact opposite of the goal (integrating observables in ES7) because it will mainly alienate developers. This is what happened with promises initially and part of why it took them a long time to get in the language.

[Jafar Husain]

I want to separate my TC-39 proposal for Observable support in JS from my position on its use in Angular.

As a rep on TC-39 I think promises are a legitimately useful primitive in some domains. They are simpler than observables, and if your problem is simple and you find them easier to understand you should use them. I am not trying to supplant promises in JavaScript, merely add support for Observables.

As far as Angular is concerned, I think Promises are too low level an abstraction for that types of asynchronous problems you run into during UI development. I think their presence does more damage than harm. If developers disagree with me and want to use promises, it's a simple matter to convert any observable into a promise (toPromise). The reverse translation is not possible without loss of semantics.

The truth of the matter is the there are very few "simple" async problems on the client. Here is a motivating example a colleague of mine building a B2B app has right now: he listens for a load event, makes an asynchronous request, uses the data in the result make multiple concurrent requests to elastic search, and once the data is loaded, animates the data on screen. This is a very common pattern and user-interface is: an event, followed by request, followed by an animation. 

Using observable for all of the steps allows him to cleanly cancel if the user navigates away from the screen. This prevents otherwise useless requests to elastic search from going out, and also saves the user from having to sit through a fade in animation when they just indicated their desire to leave the form.

That's the demonstration I would like to make to the committee using angular 2: combine together an event, a sequential request and then a set of concurrent requests, andthen finish up with an animation. However I also want to show that all of these things can be cleanly canceled if the user decides to navigate somewhere else. 

To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/3a892786-8c39-48f3-8fb1-51c7490a309b%40googlegroups.com.

[Jeff Cross]

On Monday, May 4, 2015 at 10:53:54 AM UTC-7, jhusain wrote:

Ideally angular 2. Part of the compelling reason for adding support to the language is that MVC frameworks like angular and react are taking bets on it, and supporting it natively.

Patrick and I tried to use your HTTP library in an example, but it looks like it might be a little too early still. It's also using RX Observable, not victors new observable. 

It would be great if your HTTP stuff could make it into the angular code base before the end of the month when the meeting is. What are the chances of that happening? 

Highly likely, the first couple of attempts at porting to core were blocked by our build pipeline being in flux, particularly with Typescript support., but the major blockers to this have been resolved in the past few days. It's my #1 priority to move http over to core and to build it out (more supported transport mechanisms, more helpers) starting next week. I'll be working to port to the standard observable, but I need to sync with Victor when we both are back in the office next week to see what that means.

 

If I had event, HTTP, and animation support as Observables  I could put together a very impressive code sample that motivated language support. I'm meeting with Matias today and I'm cautiously optimistic that I will be able to get him to agree to use Observable in the animation framework instead of promises.  Then I could say that angular would not have any promise support and that would be a strong motivator for observable support in the language.

There are still some parts of core that use Promise, and I'm not sure if it's on anyone's radar to revisit those. Bootstrapping for example: https://github.com/angular/angular/blob/ead21c91a41510a6fb86c5b16369c425315e9a11/modules/angular2/src/core/application.js#L252

 

JH

On May 4, 2015, at 8:49 AM, Jeffrey Cross wrote:

Hey Jafar,

Does it need to be Angular 2 examples, or would examples of using AngularJS 1.x say with RxJS be useful?

On Sun, May 3, 2015 at 7:02 AM, 'Jafar Husain' via angular-data-dev  wrote:

Hey guys,

I am on the TC 39 (JavaScript standards committee) and I need some code examples of angular data in action. I have been asked to provide examples of how better language support for observable in JavaScript could make programming Data in MVC frameworks easier.

Any code snippets you can give me that you have written would be immensely useful.

J

--

Jeff Cross

[wardb]

@jhusain

I like observables. I just don't think cancel is the most compelling argument for them.

Consider your "motivating example". 

Here is a motivating example a colleague of mine building a B2B app has right now: he listens for a load event, makes an asynchronous request, uses the data in the result make multiple concurrent requests to elastic search, and once the data is loaded, animates the data on screen. This is a very common pattern and user-interface is: an event, followed by request, followed by an animation. 

Using observable for all of the steps allows him to cleanly cancel if the user navigates away from the screen. This prevents otherwise useless requests to elastic search from going out, and also saves the user from having to sit through a fade in animation when they just indicated their desire to leave the form.

The first step is detecting the need to cancel and this is the same whether you use observables or promises, In your case, the trigger is screen navigation ... which fact is easily captured.

The (successful) promise callback can check if the screen is still active before issuing the elastic search request(s). If the screen is no longer active, no request goes out, the callback returns a reject value, and there is no animation. Problem solved.

Is it as clean? No. But is it nasty or hard? No and no. And observable cancellation isn't automatic; you have to wire it up and think about how the cancel should (or should not) propagate down the chain.

IMO, observables reveal their true value when there is a flow of multiple return values. Promises suffice for single request/response scenarios even when chained.

[Benjamin Lesh]

OMG. I think this conversation is a Promise, because no matter how we try to end it, it keeps wasting resources by trying to complete itself anyway.

observablesVsPromises.abort();
observablesVsPromises.cancel();
observablesVsPromises.dispose();
observablesVsPromises.timeout(0);
throw 'stop';

On Mon, May 4, 2015 at 1:21 PM, wardb <ward...@gmail.com> wrote:

@jhusain

I like observables. I just don't think cancel is the most compelling argument for them.

Consider your "motivating example". 

Here is a motivating example a colleague of mine building a B2B app has right now: he listens for a load event, makes an asynchronous request, uses the data in the result make multiple concurrent requests to elastic search, and once the data is loaded, animates the data on screen. This is a very common pattern and user-interface is: an event, followed by request, followed by an animation. 

Using observable for all of the steps allows him to cleanly cancel if the user navigates away from the screen. This prevents otherwise useless requests to elastic search from going out, and also saves the user from having to sit through a fade in animation when they just indicated their desire to leave the form.

The first step is detecting the need to cancel and this is the same whether you use observables or promises, In your case, the trigger is screen navigation ... which fact is easily captured.

The (successful) promise callback can check if the screen is still active before issuing the elastic search request(s). If the screen is no longer active, no request goes out, the callback returns a reject value, and there is no animation. Problem solved.

Is it as clean? No. But is it nasty or hard? No and no.

IMO, observables reveal their true value when there is a flow of multiple return values. Promises suffice for single request/response scenarios even when chained.

--

You received this message because you are subscribed to the Google Groups "angular-data-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/552cdd7a-1c3a-41f6-90d5-d7a699e089b3%40googlegroups.com.

[Jeffrey Cross]

Hey, keep it civil, Ben. I don't agree with Ward that this promise-based solution isn't nasty, and I still don't understand the resistance to observable as primary async primitive, and it may be somewhat tangential in this particular thread, but I don't want folks to feel discouraged from sharing opinions here.

[Benjamin Lesh]

LOL ... I was joking of course, Mr. Cross. I respect Ward enough to assume he'd know I was joking, I guess. It wasn't a "your momma" joke, so there's that. ;)

[Benjamin Gruenbaum]

Well, if it helps I, as well as a few other group members I spoke with in private just got the impression that there are people here who are not interested in real discussion about it so I sort of stopped the discussion in the middle.

As someone who comes from both sides and has many more arguments for observables than against them I feel there are people here who are simply not interested in discussion about which async primitive to use (promise and observable aren't the only two options, there are tens of years of research about how different mechanisms and activations work in different scenarios), what properties of it are desirable (lazy vs. eager, mutable vs immutable, always cold vs sometimes hot, single vs plural) and so on - so I stopped arguing about it. I'm not even talking about things like cancellation and retries that are brought up but are trivial with promises, meh.  

I don't appreciate the overly defensive stance, I don't appreciate the snark or the jokes but frankly - I think developers will end up being able to choose what to do anyway - just like people used promises way before they were in Angular in frameworks that didn't have them, just like I wrap some of my own code with promises or just like I use Rx observables with Angular 1.x in production just fine... the choice of an async primitive will simply not be that big of a deal. The old promise prototype for http in 2.0 was full of promise anti-patterns anyway and frankly I don't think it's what we should focus on.

That said

Things like "Then I could say that angular would not have any promise support and that would be a strong motivator for observable support in the language." make me squirm. I don't think this is how decisions should be made at all.

I think doing everything with observables is very silly including things that happen just once (and so do Rx books, and Erik Meijer, oh well) , but honestly I don't want to argue it for hours. I hope we're not shooting ourselves in the foot here with a very mediocre design decision.

[wardb]

I was ready to let this go too. But, like BG, I was spooked by the attempt to convince TC39 to support observables through an Ng design decision engineered for THAT purpose.

Jeff - I appreciate the insistence on keeping discussion civil and inviting. While I wasn't offended by the jokes (I'm pretty clueless about that actually), when in doubt it's best to promote a tolerant atmosphere ... even if it means tolerating the kind of idiocy to which I regularly fall prey (<grin/>). I'll need to be reminded of that too I'm sure.

Again ... I don't want to be "the guy who doesn't get observables". I DO want to be the guy who puts pressure on cherished assumptions. I DO want to be the guy who is thinking about the migration story. I believe it's important to minimize the cognitive dissonance and overload for the v.1.x developer striving to get to 2.0. We shouldn't let the better (observables) be the enemy of the good enough. There will be time to teach new approaches after the transition.

I am satisfied as long as promises are supported in some fashion in Ng2 ... which I understand to be the case.

I'm now "done" on this subject ... until provoked again.

[Jafar Husain]

This is a misunderstanding and it's my fault. My email was written in haste and conflated two different things. I'm currently in the process of collecting motivating examples for observable support in TC 39. That requires collecting examples from frameworks like angular 2 and react. I was under the impression that angular was going to be completely observable based and I was surprised when I learned that the animation library was using promises. When I had spoken with  Matais earlier I learned that this was not a specific choice to use promises over observables, but was motivated by a lack of familiarity with observables (this was context not in the mail). He told me he was already moving in that direction based on the teams stared preference for Observable. The problem here seems to be my use of the word "convince" which makes it seem like I was trying to talk him into it. My understanding is that it was going to be done eventually, and I wanted to convince him to do it quickly so that I could state accurately what I had always understood would be the case and has been stated on the thread several times: Angular 2 would only have observable support. If Angular is going full Observable the committee should know about it in advance so that there's time to plan features for ES7. Unfortunately my mail was very poorly written and made it seem like I was trying to get this done in order to build a case for observable. Totally understand why people would be upset about that. 

I'm hoping that some of rancor on the thread does not prevent folks from giving me the benefit of the doubt on this. For the record I have never tried to shut discussion of using Promises. It's always been my position that reasonable people can disagree on this. 

Sent from my iPad

--

You received this message because you are subscribed to the Google Groups "angular-data-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/d61b940c-e9a6-4369-aedc-ed1a6d63f880%40googlegroups.com.

[Benjamin Lesh]

Apologies, I AM the only one who attempted to stop the re-discussion of Promises vs Observables. This is only because it's been rehashed a few times already just in this Google Group. It tends to derail threads and be off-topic. It needs it's own thread, and I think it already has its own thread in this Google Group.

[blesh]

In fact, here is the thread that was started specifically for this debate, after it derailed a another thread: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/angular-data-dev/AdULPprCkbI