[4.2 RC] suggested locationfor sass for extended (custom) components

[mbudm]

With the new theme based structure I'm wondering where to put sass styles for custom views.

For example I have a class:

 [MyAppName]view.AppHeader.js

I tried the following:

/packages/[My Custom Theme]/sass/view/AppHeader.scss
/packages/[My Custom Theme]/[MyAppName]/sass/view/AppHeader.scss

But this sass doesn't get compiled on sencha ant sass theme

I also tried adding in this custom view sass into /etc, as I figured /src is just for overrides of core Ext Js components. However this doesn't work as /etc is compiled before the /vars are available and I want to use the vars in my custom sass.

So how does Sencha Cmd decide what sass to compile? From my reading so far it seems like it would use the 'requires' calls to log all components used.

Do we need to add a parameter somewhere to force it to look for custom components under our [MyAppName] in the custom theme?

[mitchellsimoens]

Cmd doesn't decide what to compile, this is the job of compass. In your app.scss did you choose to import the files? You have to tell it what to compile, it won't search the directories automatically for you.

[Navaar]

Cmd doesn't decide what to compile, this is the job of compass. In your app.scss did you choose to import the files? You have to tell it what to compile, it won't search the directories automatically for you.

This is very incorrect. SenchaCmd looks at your source files to decide what components your app is using, it then generates a .scss file called "build/{app}/{environment}/{app}-all.scss" that contains a load order of scss imports.

Themes only seem to look at files related to the base ExtJS components. Your custom component won't get compiled into the resultant .css file because it is not part of the ExtJS framework.

This is where the "sass" directory in your application comes into play. It works like the "sass" directory in a theme package, but SenchaCmd looks at the classpaths defined in your project to determine if it should include the .scss files.

The file structure is the same, sass/etc for mixins, sass/src for css source and templates, sass/var contains variable definitions. The paths should match the custom components of your app that are not part of ExtJS.

When you do a "sencha app build" it will look over all the various paths and generate a .scss file that gets compiled into the resultant .css file.

To recap:

To theme ExtJS components you need a theme.
Changes go into "{app_dir}/packages/{theme_name}/sass

To change app specific theming, you use the app local sass directory
Changes for this go into "{app_dir}/sass

"sencha app build" generates a "{app_dir}/build/{app}/{environment}/{app}-all.scss" that contains the load order for the .scss files. If you add or remove a ExtJS or custom component you need to run "sencha app build" or "sencha ant sass" to re-generate the .scss file

[mbudm]

Thanks Navaar, you saved me the job of explaining what I learned yesterday ;-)

To change app specific theming, you use the app local sass directory
Changes for this go into "{app_dir}/sass

This bit I didn't know. I was under the impression that the suggested approach was to create a custom theme for my app. I liked the idea of all style elements being in their own package.

Probably sencha intends this design decision to be left up to us users.

What I have ended up doing is simply @importing my custom views/app specific theming into the Component.scss in my custom theme sass/src directory.

I may reconsider this at a later stage but for now it will do.

Navaar do you know that if you use the approach you suggest will you have access to all the vars in your themes?

.i.e a scss file in {app}/sass can use a var from ext-theme-neptune, if thet is the theme that app is set up to use?

[Navaar]

So it looks like anything in {app_dir}/sass/var gets included before any theme variables. So you can set new defaults there.

The files in {app_dir}/sass/src get included after all the theme vars have been processed, so your source files should have access to all the variables.

You can check the generated {app}-all.scss file to see the load order.

[mbudm]

Aha, that makes it clearer which approach we should take, as our app is designed to be themed per installation, so our custom theme is effectively our base theme and this will be extended with a client theme as needed.

If we had our custom sass in the {app.dir}/sass then the client theme wouldn't be able to overwrite it.