This tutorial demonstrates this: https://angular.io/docs/ts/latest/tutorial/toh-pt1.html you don't get syntax coloring, or any benefits you'd get from a good html/templating tool.
(( flashbacks to inline html strings in C++ ))
from an angular.io example:
<li *ng-for="#el of list; #idx = index" [style.font-weight]="el.generation == generation && generation > 0 ? 'bold' : 'normal'">
Ember allows components to be called from the templates.
e.g.:
or
static assets don't have special treatment, so in your index.html, you may have something like:
<link href="app/ui/assets/styles/application.css" rel="stylesheet">
it should be just:
<link href="application.css" rel="stylesheet">
But angular-cli doesn't actually compile anything when it builds the dist directory. (keeping the dev folder/file structure)
Even when doing ng build -prod
, your dist
directory still has the entire app folder structure..
This is especially a problem when rendering tables.
if you want to use a component as a table-row, you need to specify the selector as an attribute of tr
. e.g.: <tr component-name>
.
For this type of component, it should be possible to specify the tagname that the component renders as. for example, tr
.
so, when rendering a table, you'd just do:
The angular communitive actively avoids specifying conventions, making it next to impossible to automate things (without having to build your own build process. Angular-CLI is kind of addressing this, but very lightly. there is still a ton of manual work to be done, especially when it comes to routing, static assets, and 3rd party libraries.
Because of this, there isn't a way to easily have many models. (very not scalable)
Angular should have a blessed data library that it supports and maintains. Data is too common of a problem to ignore this.
This is more of an issue with static typing in a dynamic world than with typescript itself, but for managing large amounts of models, it's easier to have them all auto-loaded, and then dynamically interacted with (like with ember-data), rather defining a typed interface for each model.
Ever had import {...} from '../../../../../../../component-name'
? being able to say .. from '@appName/component-name'
would be much nicer
I asked angular/angular-cli about this: angular/angular-cli#865 Currently, it either can't be done, or no one knows how / it isn't documented.
I have found actually that if your template is in the same folder as your component, you can do this:
@Component({
moduleId: module.id,
templateUrl: 'template.html',
...
which helps, but I feel like it should still be implicit.
There is a loose guide in the angular styleguide, but it doesn't cover anything complicated, leaving teams to come up with their own structure. I've adopted Ember's module unification RFC.
HTML isn't a templating language, and how angular interacts with it feels like a hack.
rather than doing
{{item-summary
*ngFor="let item in collection"
*ngIf="item.isTrue"
[model]="item"
}}
I'd rather do:
This is just lazy coding / design.
ngIf creates its own context, which breaks data binding. If you want something to hide/show based on the status of a property, that markup must always be in the dom via ngShow/ngHide.
This is the recommended way to use 3rd party libraries.
Add a reference to:
- packages.json
- angular-cli-build.js
- system-config.js#map
- system-config.js#packages
What angular needs is an addon system that people can develop addons for angular, so people could just do ng install addon-name
, and nothing else. For non-angular specific addons, maybe such as momentjs, they could use bower, and add a single reference to angular-cli-build.js.
I loved Angular 1 and still use it at work but I slowly started using Angular 2 for my fun home projects... until I came across ember that is!