Generator-jhipster: incomplete/failing styles setup for CSS and SASS

[xetys]

I was playing around the last days with the styles, as I need to kick off a JHipster 4 project on sass, and it was not really successfull, until I spent some hours with @arelav (my frontend guru from Viber :grinning: ) and finally made it working...

for CSS and SCSS

as of many guides for ng2 and demo code + angular cli code, there is a practice of including component specific stylesheets (scss or css), which is bound to the component.
This is not working with current JHipster state, as there is no to-string-loader, which is needed for both, css and sass.

I am definitely convinced that this is a practice we must offer to our users, as providing so much component style support, but still messing up the styles in a separate folder is not consistent to our codebase, as well as to other guides. Furthermore, the view encapsulation allows the dev not to think about ambiguous css selectors, as these files are only working for their components, and not for the whole project.

Next point, both main and vendor style are collected inside vendor.ts without any distinction in a way, what is meant to be used for vendor styles. It is rendered to disk, rather then to memory in dev mode, so it is a bit less peformant.

SASS

Due to a misconfiguration, there is a main.css generated by JHipster, which is collected by webpack, but also put on gitignore by our generator. Additionally, there is no configuration of compiling main.scss to main.css, so the whole generated project will fail on other systems (main.css will be mssing as of gitignore, sass not rendering a new one)! Obviously there is no real sass support at all.

my proposed solution

as in my current demo project I am doing the following things:

• enabling to-string-loader, so components can load their own styles
• moving main.(s)css from content/css | scss into app/layouts/main, so it is the main specific style, and is now loaded to memory
• disabling ViewEncapsulation on main component, so the main.css is affecting the whole project (and works like it did before)
• using 2 css testers with style-loader for vendor.scss, and to-string-loader for the rest

This steps were needed to be done manually, in order to make the brand new angular-material work with our angular2 app, enabling custom themes via sass.

My current reference implementation can be viewed on the link above, and @arelav is admitting, this way of doing this is more clean, than we do. It also shows, how angular material can be set up to use own theming, and demonstrates the combined power of bootstrap and material!

I will start a PR on this. Maybe even this evening.

[deepu105]

I agree that what we do might not be best but I have some concerns over the
approach suggested by angular. Ill write it in detail later as im on my
phone now

Thanks & regards,
Deepu

On 3 Jan 2017 6:12 p.m., "David Steiman" [e-mail] wrote:

I was playing around the last days with the styles, as I need to kick off
a JHipster 4 project on sass, and it was not really successfull, until I
spent some hours with @arelav https://github.com/arelav (my frontend
guru from Viber 😀 ) and finally made it working...
for CSS and SCSS

as of many guides for ng2 and demo code + angular cli code, there is a
practice of including component specific stylesheets (scss or css), which
is bound to the component.
This is not working with current JHipster state, as there is no
to-string-loader, which is needed for both, css and sass.

I am definitely convinced that this is a practice we must offer to our
users, as providing so much component style support, but still messing up
the styles in a separate folder is not consistent to our codebase, as well
as to other guides. Furthermore, the view encapsulation allows the dev not
to think about ambiguous css selectors, as these files are only working for
their components, and not for the whole project.

Next point, both main and vendor style are collected inside vendor.ts
without any distinction in a way, what is meant to be used for vendor
styles. It is rendered to disk, rather then to memory in dev mode, so it is
a bit less peformant.
SASS

Due to a misconfiguration, there is a main.css generated by JHipster,
which is collected by webpack, but also put on gitignore by our generator.
Additionally, there is no configuration of compiling main.scss to main.css,
so the whole generated project will fail on other systems (main.css will be
mssing as of gitignore, sass not rendering a new one)! Obviously there is
no real sass support at all.
my proposed solution

as in my current demo project
https://github.com/xetys/jhipster-4-sass-material I am doing the
following things:

• enabling to-string-loader, so components can load their own styles
• moving main.(s)css from content/css | scss into app/layouts/main, so
  it is the main specific style, and is now loaded to memory
• disabling ViewEncapsulation on main component, so the main.css is
  affecting the whole project (and works like it did before)
• using 2 css testers with style-loader for vendor.scss, and
  to-string-loader for the rest

This steps were needed to be done manually, in order to make the brand new
angular-material work with our angular2 app, enabling custom themes via
sass.

My current reference implementation can be viewed on the link above, and
@arelav https://github.com/arelav is admitting, this way of doing this
is more clean, than we do. It also shows, how angular material can be set
up to use own theming, and demonstrates the combined power of bootstrap and
material!

I will start a PR on this. Maybe even this evening.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/4814, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABDlF3PGVzucrhRVoLZC7QqLEOwlUXvWks5rOoGSgaJpZM4LZ0r9
.

[xetys]

I am very excited about the concerns, as view encapsulation is one of the core features of angular 2. In fact, this feature can be disabled optimal, as I did for the main.css.

However the current state makes SASS working, so I definitely want to come out in some consensus, were we find a solution where SASS is working, as this is needed very strong today.

[deepu105]

Ok first of all I'm not completeley against this idea but I dont 100% agree with what the angular/react gurus say, call me a bit old school but below are my concerns.

if you are building an app which is gonna have 100% custom styles for each and every component then it makes sense to follow this pattern and apply styles per component, this is more applicable for desktop apps built with electron and stuff or for products with very specific style guides (Ionic, material etc) but in real world cases you mostly end up using something like bootstrap and almost in all cases you would want some sort of common style sheet for the app.
If you write all the styles only in components in the end you just end up duplicating a lot of the declarations and i kind of feel that its going back all the way to writing style inline in each page pre css style sheet era (i know its a bit exaggerated)
so given that I would prefer something like below

a global style-sheet (similar to what we have now which is applied to the entire app to have global styles, vendor overrides, bootstrap tweaks etc) as i feel this is more practical
inline styles/or style-sheet in the component folder for styles which is very specific for the component only or if you need some scoped overrides tweaks
if a style needs to be applied in more than one place it should go into the global style-sheet

so i have looked at the PR and it doesn't change anything drastic other than the main css/scss file so in theory its good. Now my only worry is you disable shadow DOM for the main element and I dont know if that will be an issue for any use case hence I would prefer we have a global stylesheet loaded to head as its is today and then also generate/support a style-sheet per component as well

[xetys]

turning view encapsulation off on main component is disabling shadow dom only for this component, but not for the embedded.

To your concern about the global stylesheet, you still can put your global stylesheet inside main css, like before, so there is no must to use component level stylesheets. This is why view encapsulation is turned off.

[deepu105]

I understand that but im just saying if somebody wants to scope some style
to the main component itself it will not be possible then they would have
to make another wrapper. Thats why i prefer a global stylesheet and then
scoped ones when required

Thanks & regards,
Deepu

On 3 Jan 2017 11:55 p.m., "David Steiman" [e-mail] wrote:

turning view encapsulation off on main component is disabling shadow dom
only for this component, but not for the embedded.

To your concern about the global stylesheet, you still can put your global
stylesheet inside main css, like before, so there is no must to use
component level stylesheets. This is why view encapsulation is turned off.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/4814#issuecomment-270249432,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF42Wvu3pU6DLrm9WX1sJ0x_CZvJPks5rOtH0gaJpZM4LZ0r9
.

[xetys]

in the "ideal" use case, there should not be much custom code on the main component, as it is used to collect the downgoing components.

as an alternative I can do the same trick to main.css like I did for vendor.css already. This wouldn't change a lot, but you then could scope a encapsulated main component as well..

should I add a an empty css/scss file generation for entities, to show this is possible, or just point at this feature in documentation? if yes, here ore another PR?

[deepu105]

I think we could either add documentation or an empty css but then there
might be too many empty css. So im leaning towards documentation with a
sample on our home screen and navbar which has some custom css that can be
scoped

Thanks & regards,
Deepu

On 4 Jan 2017 12:10 a.m., "David Steiman" [e-mail] wrote:

in the "ideal" use case, there should not be much custom code on the main
component, as it is used to collect the downgoing components.

as an alternative I can do the same trick to main.css like I did for
vendor.css already. This wouldn't change a lot, but you then could scope a
encapsulated main component as well..

should I add a an empty css/scss file generation for entities, to show
this is possible, or just point at this feature in documentation? if yes,
here ore another PR?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/4814#issuecomment-270252179,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF-EJ2FuW4LzRKQhapMFTaFD-QQkKks5rOtV4gaJpZM4LZ0r9
.

[wmarques]

I agree with most of what @deepu105 said, however when you do component you might want to customize it without doing it in one big css file, it prevents also from impacting other elements in your app.
So i'm ok for the solution you proposed, keep a "main" file containing the Bootstrap tweaks and global customizations, and let's add navbar/home stylesheets to show our users how to customize a component :+1:

[xetys]

one of my problems was, that we load the global style inside vendor, and this feels really wrong. But its needed, as a user defined global style has nothing to do with vendor, and vise versa...

as I am not the frontend expert here, I just tried another approach by adding the global style into webpacks entry. It works, but dunno if this is inaccurate for some reasons...

so long, global css returned to both sassy and css, and works...