[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.

[dongryphon]

Apologies for not having the documentation updates posted but here is a summary of this process.

The files in ./sass/src and ./sass/var are selected by correspondence to JavaScript classes. The connection from JS class to files in these folders is roughly this:

- the prefix specified by app.sass.namespace (for apps) or package.sass.namespace (for packages) is removed
- the remainder is split on dot and joined by path separator
- the ".scss" suffix is added

So "MyApp.view.Foo" turns in to "view/Foo.scss" by default since app.sass.namespace defaults to MyApp.

If that file exists in ./sass/var it is included early to set variables. Variable files are included "backwards" so that app variable files are included before the theme and other packages. This allows app variables to take priority over the !default values in the those var files.

If that file exists in ./sass/src it is included later to define rules and such. Normal SASS source is included "forwards" such that app sass src files come after the theme and other packages so that app rules can cascade later and override styles properly.

Inside these groupings, the individual order of scss files from a common package or app are included in JS class order. In other words, the vars for a base class are included before those of a derived class inside the same group. The same is true of files ./sass/src.

[mbudm]

Apologies for not having the documentation updates posted but here is a summary of this process.

It's in beta, we're gonna find issues before you document them.

So "MyApp.view.Foo" turns in to "view/Foo.scss" by default since app.sass.namespace defaults to MyApp.

I figured that would be how it should be done and I did try this method. It doesn't work for me:



For example I have a class:

{appName}.view.Appheader.js

And I have an scss file in my theme src at

/{themeName}/sass/src/view/Appheader.scss

When I run sencha ant sass theme the {appName)-all.css updates but there is no css from /{themeName}/sass/src/view/Appheader.scss

Edit: I also just checked my sencha.cfg for the app, the var is set correctly:
app.sass.namespace=IesExpert

(My app name is IesExpert)

[dongryphon]

Sounds like maybe the theme package does not have the proper sass namespace. By default a generated app has its namespace as its "app.sass.namespace" assuming you will not want to apply styles to things outside your namespace.

A theme package I believe defaults its "package.sass.namespace" to blank so that it can style anything. If that is true, there are two ways to go:

#1 - you can set package.sass.namespace to your app's namespace if that is all it needs to style and preserve your folder structure in ./sass/src (and ./sass/var)

#2 - you can move the content of your theme down inside a folder named by your app's namespace.

Let me know if that works for you... or doesn't

[mbudm]

Thanks Don.

#1 - you can set package.sass.namespace to your app's namespace if that is all it needs to style and preserve your folder structure in ./sass/src (and ./sass/var)

This does compile the src/view/CustomeAppView.scss

But of course it doesn't compile anything Ext.* (in src and var) which also means we don't have access to all the ancestor theme sass vars

#2 - you can move the content of your theme down inside a folder named by your app's namespace.

Let me know if that works for you... or doesn't

This is a much better solution for our setup, I havebn't fully tested it yet but it seems to compile everything we need.

Just to make it clear for others, here's our custom theme package directory structure now:

• CustomTheme
  • ...
  • sass
    • ...
    • src
      • Ext
        • All Ext customisations in structure that matches Ext.*
      • AppName
        • All custom app views in structure that matches AppName.*
    • var
      • Ext
        • Vars also need to be 'namespace' otherwise they don't compile
    • ...
  • ...

( In sencha.cfg we set package.sass.namespace= )