I believe this is already covered here: ee3f709 We have decided to treat style and class special for now.

Love your enthusiasm, but you should check with me to make sure you are not duplicating work. Angular2 has slightly different philosophy, and so we don't want to just copy everything we did in Angular1

I am going to close this as we are not planning to solve this in this way. We will certainly revisit if we change our mind.

The idea behind this is providing a simple interface while leaving implementation up to the user. The user can compose their styles any way they like rather than the framework suggesting it. For example how to do maintain a simple component in one fine with vendor prefixes and other jazz you normally get from gulp build

import {Component, Template} from 'angular2/angular2';
import {ngTemplate, ShadowDom, toObject} from ' pseudo-ng-api/angular2';
import {stylus} from 'stylus/angular2';
import {prefixer} from 'cssprefixer/angular2';

var styles = toObject(prefixer(stylus`
  someButton {
    color: blue;
    background-color: white;
  }
  someContext {
    text-transform: uppercase;
  }
`));
var template = ngTemplate(ShadowDom`
  <awesome-component [style]="awesomeStyles.someButton">
    <content [style]="awesomeStyles.someContext"></content>
  </awesome-component>
`);

@Component({ selector: 'awesome-component' })
@Template({ inline: template })
class AwesomeComponent {
  constructor() {
    this.awesomeStyles = styles;
  }
}

you can almost imagine compiling components from html imports into js

@gdi2290 I'm not sure what would be the added value of putting so much style info into JS vs. moving those to CSS. Could you please elaborate, in your own words, what would be the main advantage?

BTW: we want to support more sophisticated support for styles, similar to ngStyle from Angular 1.x but it is pending some changes to the change detection.

The value above has the advantage of maintaining a small component in one file just by eliminating how many files you need to touch. Although, we may already be on the same page; I'll try to explain my reason behind this style.
When using <style> you're setting the styles once for your component which is fine until you need dynamic styles or inheriting global styles. A few example for dynamic styles would be: a/b testing, feature toggling, or even layouts height/width that depend on collection size.

Here is an example for pseudo a/b testing a button being controlled by the "server" in realtime.

<template>
  <button
    [style]="styles.button"
    (click)="changeColor(1 - feature)"
  >{{ styles.content.button }}</button>
</template>

<script type="text/atscript">
@Component({
  selector: 'cta-button',
  directives: [
    Autofocus,
    Style
  ]
})
@Template({  url: 'cta-button.html', })
export class CtaButton {
  feature: number;
  featureStyles: Array;

  constructor() {
    this.feature = 0;
    this.featureStyles = [
      {
        button: {
          backgroundColor: 'purple'
        },
        content: 'Submit Here'
      },
      {
        button: {
          backgroundColor: 'yellow'
        },
        content: 'Click Me'
      }
    ];

    this.styles =  this.featureStyles[this.feature];

    };

    // Just to randomly show changes from the server
    setInterval(() => {
      var input = this.randomVal();
      this.changeColor(input);
    }, 1000);

  }
  changeColor(input) {
    this.feature = input;
  }

  get styles() {
    return this.featureStyles[this.feature];
  }

  set styles(feature) {
    return this.featureStyles[feature];
  }

  randomVal() {
    return Math.floor((Math.random()*10) % this.featureStyles.length);
  }

}
</script>

With the example above you have a button that is randomly toggling between to styles. We can provide these hooks for the server to manage in real time allowing them to add more experiments. We would inject/control/study the experience for users that we observe in realtime. We could also fix styles for something like a mobile app where submitting updates takes 2 weeks at minimum (due to iOS processing) being able to submit hot code fixes while the app is being processed has a lot of benefits. Styles are just one part of what I need component to do. Like I said we may be on the same page depending on what you mean by sophisticated support for styles. I'm suggesting that you can do a lot already with what I'm using here for prototyping. If I can get styles to be considered more of a first class citizen like templates or javascript then I'll be happy

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}