-
Notifications
You must be signed in to change notification settings - Fork 22
Add instead of override? #18
Comments
Hmm, I've experimented with it and now experiencing an opposite problem. I have the topmost state: .state({
name: 'root',
abstract: true,
data: {
css: ['/css/application.css']
}
} And the leaf state: .state({
name: 'foo',
parent: 'root',
data: {
css: ['/css/foo.css']
}
}) And for some reason when I load the Thanks! |
Yes because the plugin works like you've described in the issue. In this example the |
I can add an option to change the plugin behaviour, can be a solution? |
Yes, this could be a solution for my concrete example, but then we will have another issue where we will want to add instead of override. I've got an idea of named styles, I've described it here: castillo-io/angular-css#55 (comment) This would be the best possible solution in my opinion. |
However, I will appreciate the quick fix if it's possible = ) |
Here a working version that implements your named styles idea. I'll write tests and release the new version until tonight (here GTM+1). |
Wow, that was fast = ) |
👍 |
I've tested the latest version of the module in our project and it works amazing! Thanks again @manuelmazzuola, great work! Right now, it's the best conditional stylesheet module for Angular.js for sure. We're going to use it in all of our projects. However, I've stumbled upon some other good ideas of how it could be improved. I'm going to share them with you: 1). There is no direct way to disable some named style in the state down the chain. Consider this example: // The root state:
.state({
name: 'root',
abstract: true,
data: {
css: [
{
name: 'layout',
href: 'primary-layout.css'
},
{
name: 'fancybox',
href: '/vendor/fancybox/jquery.fancybox.css'
},
{
name: 'intl-tel-input',
href: '/vendor/intl-tel-input/css/intlTelInput.css'
}
]
}
})
// Some child state
.state({
name: 'bar',
parent: 'root.foo'
data: {
css: [
{
name: 'layout',
href: 'another-layout.css'
},
{
name: 'fancybox',
href: 'empty.css'
},
{
name: 'intl-tel-input',
href: 'empty.css'
}
]
}
}) Right now I have to use 2). Named styles construct is too bulky, what if we could support a minimalistic hash notation? .state({
name: 'root',
abstract: true,
data: {
css: {
layout: 'primary-layout.css',
fancybox: '/vendor/fancybox/jquery.fancybox.css',
extended: {
// name: 'extended' implied
href: 'extended.css',
'some-other-property': 'value',
'some-more-property': 100500
},
$unnamed: [
// Some other unnamed styles:
'foo.css',
'bar.css',
'baz.css'
]
}
}
}) 3). What if we could advance the idea of named styles further and create a named groups of styles? Often, the layout consists not only of the single css file, but also requires some other vendor files. Please consider this example: .state({
name: 'root',
abstract: true,
data: {
css: {
layout: [
// All CSS files of the primary layout are grouped together under the "layout" named group
'bootstrap.css',
'primary-layout.css',
'/vendor/fancybox/jquery.fancybox.css'
],
overall: [
// The entry of the named group list could be either a string as above
// or a hash-object with additional options
{
href: 'animate.css',
'some-other-property': 'value',
'and-another-property': 100500
}
]
}
}
})
.state({
name: 'bar',
parent: 'root.foo',
data: {
css: {
// Overloading the entire layout by a single CSS file
layout: 'alternative-layout.css'
}
}
}) Actually, I think that named groups approach will be able to replace named styles and unnamed styles entirely. In my opinion, it's very flexible approach that will allow developers to build a very robust layout schemes. I'm sorry I couldn't help with the implementation of this ideas right now, however I will be very glad to rewrite the README and to write some beautiful and comprehensive documentation for this module if you choose to implement those ideas. Probably I could ask our designer to even draw some logo for this module and to craft a small website if required. What do you think? Cheers! |
I'm glad to see that this module is useful to you and to other people. I'll try to implement those enhancements in these days. Thank you @slavafomin for the ideas 👍 |
Thank you! I will be looking forward for the new features in order to test and verify them. After that I will be glad to update the docs. And yet after that, you will be able to ship a new major release, By the way, why don't we move Also, why do this module require the directive to operate? Is it possible to remove the directive? It will make configuration easier and even more straightforward. Actually, I've forgot to add the directive earlier today and spent almost 20 minutes trying to figure out why the module is not working = ) What is the value of using the directive from the end user perspective? |
Well, angular recommendations say that the DOM should be modified only by a directive, and I think they are right so a directive is necessary, what do you think about it? The |
I totally agree with the recommendation regarding the directives, it makes sense from the abstract perspective: if every module will manipulate entire DOM of the document on it's own accord, it will bring chaos to the application. However, in our case, the manipulation is very limited and highly predictable. I didn't think it will hurt someone in practice, on contrary it will make the life easier. In my opinion it's totally safe to get rid of the directive in our concrete case. However, if you want to play strict and by the rules, then the directive should be placed where you want your <html>
<head>
<title>Hello World!</title>
<link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png">
<ui-router-styles-css-links></ui-router-styles-css-links>
</head>
<!-- ... -->
</html> That will make more sense than putting it on the body element as an attribute. However, again, according to the specs: |
Regarding the |
Yes, I agree with you about the |
I think the module should be entirely configured from the router's configuration or through the service provider. I just can't really see any practical benefits of using the directive = ) |
👍 |
Hello!
Thank you for this module!
Is it possible to have hierarchical CSS files applied to the final state or the last state will re-define the entire list? I have application with multiple hierarchical layouts and I want to have global CSS files for entire layouts as well as custom CSS files for some states. I want to keep things DRY of course, i.e. not to re-define the entire list for each "leaf" state.
Thank you!
The text was updated successfully, but these errors were encountered: