<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="[ x ] bug report =&gt; search github for a similar issue or PR before submitting
[ ] 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">[ x ] bug report =&gt; search github for a similar issue or PR before submitting
[ ] 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>
After upgrading to 4.0, the trigger state name evaluation has changed. For example, a boolean value <code class="notranslate">true</code> doesn't match to a state named "true", which used to work on <code class="notranslate">v2.4</code>. I'm not sure whether the previous or the current behavior is the planned/desired one, but in any case, my guess would be that this is a regression issue or an undocumented change happened. Additionally, truthy and falsy values such as <code class="notranslate">0</code> and <code class="notranslate">1</code> behave unexpectedly (see repro examples 3 and 4).</p>
<p dir="auto"><strong>Expected behavior</strong><br>
Both string and truthy/falsy values should behave predictably when used as state trigger names. Particularly boolean values are often used for state, as shown on the first rest in the repro below; truthy and falsy values—on the other hand, perhaps—sit more subjectively in that equation.</p>
<p dir="auto"><strong>Minimal reproduction of the problem with instructions</strong><br>
I've setup a few test cases of scenarios I felt were worth exploring to exemplify the issue. Strings behave reliably to maintain state, whereas booleans or otherwise truthy/falsy values behave unreliably.<br>
<a href="http://plnkr.co/edit/12iB5WLvRxl3MkoxOpkk?p=preview" rel="nofollow">http://plnkr.co/edit/12iB5WLvRxl3MkoxOpkk?p=preview</a></p>
<p dir="auto"><strong>What is the motivation / use case for changing the behavior?</strong><br>
Although ensuring strings to match state is not a difficult thing to achieve, I think people might expect booleans particularly to match "true" and "false" state names.</p>
<p dir="auto"><strong>Please tell us about your environment:</strong><br>
OX X 10.11, VScode, Yarn, Webpack Dev Server</p>
<ul dir="auto">
<li>
<p dir="auto"><strong>Angular version:</strong> <code class="notranslate">4.0.0</code>, resolving to <code class="notranslate">es2015</code> modules</p>
</li>
<li>
<p dir="auto"><strong>Browser:</strong> All</p>
</li>
<li>
<p dir="auto"><strong>Language:</strong> TypeScript 2.2.1</p>
</li>
<li>
<p dir="auto"><strong>Node (for AoT issues):</strong> <code class="notranslate">node --version</code> =  <code class="notranslate">v6.9.5</code></p>
</li>
</ul>
<p dir="auto">In <a href="https://angular.io/docs/ts/latest/guide/ngmodule.html" rel="nofollow">the section on NgModules</a>, after introducing the shared module, the core module does not import the shared module and instead imports the CommonModule directly. The document provides no explanation and it seems some kind of anti-pattern. Is there any reason not to import the shared module into the core module?</p>