<p dir="auto"><strong>I'm submitting a ...</strong>  (check one with "x")</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="[ ] bug report =&gt; search github for a similar issue or PR before submitting
[x ] feature request
[ ] support request =&gt; Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question"><pre class="notranslate"><code class="notranslate">[ ] bug report =&gt; search github for a similar issue or PR before submitting
[x ] feature request
[ ] support request =&gt; Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre></div>
<p dir="auto"><strong>Current behavior</strong><br>
these are seperated</p>
<p dir="auto"><strong>Expected behavior</strong><br>
become one</p>
<p dir="auto"><strong>Minimal reproduction of the problem with instructions</strong></p>

<p dir="auto"><strong>What is the motivation / use case for changing the behavior?</strong><br>
it made confusion for my colleagues to refer them.  and it is strange to deal with the same element (form) in different places in the same core.</p>
<p dir="auto"><strong>Please tell us about your environment:</strong></p>

<ul dir="auto">
<li><strong>Angular version:</strong> 2.3</li>
</ul>

<ul dir="auto">
<li><strong>Browser:</strong> [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]</li>
</ul>

<ul dir="auto">
<li>
<p dir="auto"><strong>Language:</strong> [all | TypeScript X.X | ES6/7 | ES5]</p>
</li>
<li>
<p dir="auto"><strong>Node (for AoT issues):</strong> <code class="notranslate">node --version</code> =</p>
</li>
</ul>
<p dir="auto">This is probably best classified as a Router feature request. I'll describe what it is, my thinking, and a use case.</p>
<p dir="auto">What it is: Currently, the V3 Router waits for an Observable to Complete before completing navigation. I would like for it to instead continue navigation after the first Observable item is returned.</p>
<p dir="auto">My thinking: Currently the Resolve treats the Observable as a Promise, defeating the power of the Observable. This doesn't present a barrier with Angular's Http, where only one item is returned. But unless I misunderstand, the point of using an Observable in Http is to allow easy extension throughout Angular into a scenario where the data is actually a stream.</p>
<p dir="auto">Use case: I have a live data feed from a remote server. I subscribe to a resource, rather than get it. When viewing this resource in a page, I only need one snapshot to complete navigation and display the component, but I would still like the updates bound to the view.</p>
<p dir="auto">More detail:</p>
<p dir="auto">Observables as first-class citizens in Angular2 are great for displaying "live data". I currently rely on, and it is becoming more common to integrate, "live data" streamed/syndicated/published from web services. Regardless of the framework used to deliver streams to the client, Observables are the obvious choice to act as intermediary between the receiving agent/service and the view.</p>
<p dir="auto">Resolvers in Angular are also very nice for a few reasons. One is that I can be sure I have all my data before performing initialization. This greatly simplifies my component initialization logic. It also simplifies managing built-in operations Angular performs, such as avoiding errors binding templates to properties on null models.</p>
<p dir="auto">But where live data comes in, the current Resolve behavior is difficult to make use of. If we suppose the live data stream never completes, we have to instead resolve, for example, to Observable.first(), and throw away the remainder of the stream.</p>
<p dir="auto">Or I can go through extra steps for each of my Observables, to Observable.publish etc. But that's not enough, because there's not a symmetric exit hook for resolve, that I see. So instead I have to do some extra magic, such as tear down resources I didn't initialize in the component.</p>
<p dir="auto">IMO, in the spirit of Rx, a better behavior would be to:</p>
<ul dir="auto">
<li>Share the Observable, e.g. via PublishReplay</li>
<li>Connect</li>
<li>Subscribe</li>
<li>Wait for the first item</li>
<li>Unsubscribe</li>
<li>Complete navigation</li>
<li>Pass the shared Observable as ResolvedData</li>
<li>When exiting navigation Disconnect</li>
</ul>
<p dir="auto">Or something similar.</p>
<p dir="auto">Your thoughts are appreciated. I'll also be happy to contribute effort if someone with design authority confirms an approach.</p>