Best practice for overriding SASS mixins with new package structure.

Hi guys,

I'm just wondering what everyones thoughts are on overriding mixins on the new theme structure?

Previously we would create a whole new theme and edit the mixin directly and then workout the differences between new ExtJS versions using a diff and apply any changes that were relevant to our mixin. Super messy!

Now that we are extending an official themes, we still want to editing the original mixins. Currently we are just creating a file, in src/window/Window.scss for example, that copies the whole mixin from the natural theme. Then editing what we want to change.

Now this appears to work OK because our one is loaded last, but still feels messy, especially after all this work has been done by Sencha to make theme editing a lot more managed!

If anyone has any insight it would be great to hear it!

UPDATE: Just noticed that this practice causes an error in the slicer when packaging the theme.

The widget undefined declares two corners with two different urls
== Unhandled Error ==
The widget undefined declares two corners with two different urls

Just curious, what are you trying to do here? Is there a missing feature from the extjs-window-ui mixin? Perhaps a new parameter that needs to be added?

There are 2 problem with overriding UI mixins:
1. Because of the way the files are ordered, the "default" UI will use the neutral theme's mixin, not your overridden one. If you're not using the default UI it will get generated anyway, consuming extra space. I've opened a ticket for this becuase we should really provide a way to prevent the "default" UIs from being generated, if you decide not to use them.
2. once you've duplicated the mixin, you've essentially "forked" a large portion of the code, and you won't get bug fixes to the mixin going forward.

I would recommend that if there is some missing feature or bug fix required in the framework's UI mixin, we should fix it there, and I would hope overriding a UI mixin in your theme would not typically be necessary. If you find it really is necessary, the way you are doing it will work fine, you'll just have extra "default" UI rules that may not be used.

Specific examples are wanting to add gradients to Window headers. Text shadows to various parts. There are quite a lot of components that are not configurable without changing the mixin currently.

I understand that this is not the preferred way of doing it, which is why I was wondering what the best way should be. At least the new structure for 4.2 theming makes life a bit easier when tracking changes to the original mixin. Before it was a nightmare

If you want, I'm happy to work with you guys to add in extra configurable parts that would be nice for your themes. We've had to change a few of them when updating our clifton theme to work with 4.2.

If you want, I'm happy to work with you guys to add in extra configurable parts that would be nice for your themes.

Thanks for offering. Feel free to post your wishlist here, and I'll open a ticket for it. Just list the component sand the things that you wish were configurable via mixin but aren't currently, and I'll see which ones are easy enough to include in the framework mixins.

The error occurs because the mixin in ext-theme-neutral gets automatically called with "default" as the UI name, and when you copied the file into your theme, it calls the mixin a second time with "default" as the UI. This results in duplicate rules being generated with different image paths.

In Ext 4.2.1 we will provide sass variables for supressing generation of "default" UIs. For example:

Code:

$include-toolbar-default-ui: false;

For now you can work around it by changing the $ui parameter in your Toolbar.scss to something other than 'default'

Code:

@include extjs-toolbar-ui( $ui: 'my-custom-ui',
...
);

You will also need to add your custom UI to shortcuts.js as described in the theming guide if you want the slicer to generate background images for IE.