Issue 1:
I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When creating a new Observable inside a @Component it won't be automatically disposed once the component is being destroyed (unless it is hooked to an async pipe).

Expected behavior

I would expect the Observable to be automatically destroyed unless specified not to.

Minimal reproduction of the problem with instructions

Here's a brief implementation of a lazy load mechanism in a chat application:

lazyLoadMessages() {
this.autoScroller = this.autoScroll();
this.subscribeMessages();

// Get total messages count in database so we can have an indication of when to
// stop the auto-subscriber
this.countMessages().then((messagesCount) => {
Observable
// Chain every scroll event
.fromEvent(this.scroller, 'scroll')
// Remove the scroll listener once all messages have been fetched
.takeUntil(this.autoRemoveScrollListener(messagesCount))
// Filter event handling unless we're at the top of the page
.filter(() => !this.scroller.scrollTop)
// Prohibit parallel subscriptions
.filter(() => !this.loadingMessages)
// Invoke the messages subscription once all the requirements have been met
.forEach(() => this.subscribeMessages());
});
}

The code snippet above loads more messages whenever scrolling to the top of the page in the messages page. If I don't stop this Observable manually in the onDestroy callback, there might be a potential memory leak and unnecessary requests made in the background. The full component can be found here.

What is the motivation / use case for changing the behavior?

Lots of developers might forget to handle their observations which may lead to a total disaster with unnecessary requests and processes running in the background. Observables should be disposed by default unless specified else wise. It's hard for me to think of a scenario where the developer wants the Observable to keep running in the background despite the fact that the component has been already disposed long ago, it will only cause slow downs and issues.

It would be a good idea to create a dedicated service called NgObservable where it can be injected to the component and be used to create new Observable instances which are bound to the component. After a brief thinking of how the service should look like led me to the following result, which might inspire you and give you an idea what I'm actually talking about:

import { Observable } from "rxjs";

/* Declarations */

// Save duplicate importations
export interface NgObservable<T> extends Observable<T> {
_keep: boolean;
};

// Will define a dynamic interface based on the current version of "rxjs" installed
export interface NgObservableService extends Rx.ObservableStatic {
readonly keep: NgObservableService;
};

/* Implementations */

// Creates new Observable instances through its prototypical methods.
// The constructor only holds options which should be applied to these instances
export class NgObservableService {
private _keep: boolean;

constructor({ keep }: { keep?: boolean } = {}) {
this._keep = !!keep;
}
}

// Solves "Index signature is missing in type" error:
// https://github.com/Microsoft/TypeScript/issues/1887
const IterableObserver = Observable as { [key: string]: any };

// Delegating all kind of Observable factory functions like 'of', 'from' etc.
// The advantages of automatically generated prototype are that we're always gonna
// be correlated with the currently installed Observable API
Object.keys(Observable).forEach((key) => {
const value = IterableObserver[key];

// Delegate function
if (typeof value == "function") {
const methodHandler = function () {
const observable = value.apply(Observable, arguments);

if (observable instanceof Observable) {
const ngObservable = observable as NgObservable<any>;
ngObservable._keep = this._keep;
}

return observable;
};

Object.defineProperty(NgObservableService.prototype, key, {
configurable: true,
enumerable: true,
writable: true,
value: methodHandler
});
}
// Delegate value
else {
Object.defineProperty(NgObservableService.prototype, key, {
configurable: true,
enumerable: true,
get() {
return IterableObserver[key];
},
set(value) {
return IterableObserver[key] = value;
}
});
}
});

// The "keep" getter will make sure that created observables won't be disposed
// automatically once their belonging components are being destroyed,
// e.g. this.observable.keep.of([1, 2, 3]);
Object.defineProperty(NgObservableService.prototype, "keep", {
configurable: true,
enumerable: true,
get() {
return new NgObservableService({ keep: true });
}
});

The biggest advantage of the code snippet above is that it's generic and it will work with whatever rxjs version currently installed in your project, you don't even need to be worried about maintaining this module. Unfortunately this is not something that can be provided as a third-party service since the auto-disposal mechanism should be hard-coded in the angular library, since a service has not direct effect on a component. The implementation above is only a partial implementation of a bigger picture. I believe there should also be few additions made in the application_ref.ts file where onDestroy callbacks are being registered.

Moreover I would like to know why my feature request is not a good idea and what reason do you have to decline it, if at all. Let's discuss about it first and I would like to know your thoughts of such a feature.

Issue 2:
I'm submitting a ... (check one with "x")

[x] bug report
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

I created a new Component and set style using styleUrl property. This works with no problems, but i can't debug it in my browser.

Expected/desired behavior

Since Angular2 injects the code within <style> tag it prevents styles code to be paired with CSS source files. I would like to get sourcemaps for CSS files.

Reproduction of the problem

Here is an example of Component:

import {Component} from '@angular/core';

@Component({
moduleId: module.id,
selector: 'home',
templateUrl: 'home.component.html',
styleUrls: ['home.component.css']
})

export class HomeComponent {
}

What is the expected behavior?

I expect to see sourcemaps for style files in Chrome inspector, but this doesn't happen.

What is the motivation / use case for changing the behavior?

I would see CSS files mapped in sourcemaps to easily debug style in my projects.

Please tell us about your environment:

Angular version: 2.0.0-rc.4

Browser: Chromium 50.0.2661.102 Built on Ubuntu 14.04, running on LinuxMint 17.2 (64-bit)

Language: TypeScript 1.8.10