Sencha Cmd is not importing this package's component-specific rules or vars into application

[johnyanarella]

@dongryphon

You might remember me from the conversation you, Isaac Johnston and I had regarding Deft JS and Sencha Cmd at SenchaCon this year. We're continuing to refine our integration with Sencha Cmd on the Deft JS project as it continues to evolve (thanks for jumping in on the issue comments there!). I'm also trying to understand how I might use Sencha Cmd to distribute various UI components I've built for Sencha Touch and Ext JS. My hope is that these open-source components will be useful to others in the Sencha developer community and serve as a model others can follow for sharing components of their own.

Ext.ux.plugin.ScrollToTop is a plugin for the Sencha Touch Ext.List component that adds a floating button that animates into view once the user scrolls past a configurable threshold. Tapping this button animates the button back out of view, and scrolls the list back to the top (with a configurable animation duration). This is modeled after a feature of Facebook's native application for iOS. This component will be open-source under the MIT license.

I am attempting to create a signed redistributable Sencha Cmd package that can easily be required into third party developer's Sencha Touch applications. (I also intend to add the necessary metadata to make the package compatible with Sencha Architect 3.0, but I haven't gone down that road yet.)

This repository contains a workspace with the component defined within a package and an example application that uses that package.

The "ext-ux-plugin-scrolltotop" package includes the Ext.ux.plugin.ScrollToTop component:

packages/ext-ux-plugin-scrolltotop/src/ux/plugin/ScrollToTop

and supporting SASS rules and vars:

packages/ext-ux-plugin-scrolltotop/sass/var/ux/plugin/ScrollToTop
packages/ext-ux-plugin-scrolltotop/sass/src/ux/plugin/ScrollToTop

I've gone to great lengths to make the appearance highly customizable via these SASS vars.

package.sass.namespace is still set to the default Ext value, and I've mirrored the package structure between the JavaScript component source and SASS files. My understanding is that by segmenting these files in this manner, Sencha Cmd will only pull in the rules and vars that correspond to the components that are actually referenced by the application (in the hypothetical scenario there were more than just one component in this package).

To successfully build the package with Sencha Cmd (v3.1.2.342) I had to modify the package's sencha.cfg to add the skip.slice and skip.style flags. Otherwise, the resulting build failed (with the slice step enabled) or resembled a theme (with the style step enabled). I mention this since in case it's related to the issue at hand.

So here's the problem:

When I require this package in to the Example application, when I build the application, the rules and vars are not included.

Further, I'm also unclear as to when the default vars and rules would be loaded relative to the application's app.scss declarations. I assumed they would be automatically imported after the app.scss content. If a developer wanted to customize the vars would they need to explicitly @import the vars and rules from the package directory?

What am I missing here? :)

Thanks for any guidance you can provide!

On an unrelated note: as I've gotten further into this, I've been considering moving away from the "Ext.ux" namespace. Is there any guidance in the works from Sencha on naming of packages and class packages in this brave new Sencha Cmd world?

-John

[dongryphon]

There are some differences between how Touch 2.3 handles Sass and Ext JS handles it. I'd like to @kkrohe here and get his take (our lead Cmd dev) and where we are on the unification of this and what we might do today on the Sass vs Touch question.

On the namespace thing, I never was a fan of Ext.ux personally. But in the wider world of multi-authorship I would go the route of root level namespaces for things. For example how Bryntum has used Sch and Gnt (http://www.bryntum.com/docs/scheduling/)

[johnyanarella]

Good to know. I went with Deft as the root namesplace for Deft JS, since I was just coming to Sencha's frameworks from other technologies and the Ext.ux convention didn't make much sense to me. I plan to rename this package and reparent the class to a different namespace before releasing this.

Added @kkrohe to the repo so he can join the conversation here.

Thanks Don!

[kkrohe]

Using Cmd to build a filtered set of sass src and vars currently requires that the app be setup to use theme packages, and we do not yet have a version of touch that has the styling extracted out into theme packages as we do with Ext JS. Consequently, using cmd to inject the styling from the component package directly into the app's css content won't work just yet, so you'll need to use one of the new features in Cmd 4.0.

One of the things new to Cmd 4.0 is the ability for cmd to combine js, css, and resource content from app.json with content supplied by all required packages in their respective package.json files. With that, the approach I'd recommend here is this:

1.) Run the package build to produce the package's css and resource content. Setting skip.slice=1 is good here, since you won't need the sliced images for a touch application. You'll want to include this built content into the package's distribution zip, but it should be by default, so you may not need to modify anything to achieve that.

2.) In package.json, create a "css" property and add the built css file into that array

3.) In package.json, create a "resources" property and add all resource paths to that array that need to be copied to the application's build folder.

4.) You may also need to set "package.resource.paths=" (set to empty string) in .sencha/package/sencha.cfg to prevent resources from getting copied to the application's build folder multiple times.

You'll end up with some new entries in package.json that look similar to entries in an application's app.json file (note: all paths are relative to the package's package.json file, so they will ideally be contained in the package distribution zip file):

"css" : [{
  "path" : "build/ext-ux-plugin-scrolltotop-all.css"
}],
"resources" : [
  "build/resources"
]

As the compiler will be able to combine the js code with the app's code directly, you shouldn't need to add any elements for js files, just need to deal with the styling in this case.

If you have an application upgraded to at least Cmd 4.0.0.161, which is the latest RC release, what that will do is cause your package's declared resources to get added into the app.json content in between elements for content from the touch framework and elements for content from the application. You'll see this is both the application's built app.json file, as well as the new "bootstrap.json" file that gets loaded by the development microloader.

This will allow you to supply the styling needed from the package itself, and users can still override rules as needed, but without theme package support for touch, users will just have to manually code up the rule overrides in app.scss and won't be able to use sass code directly from the package.

Eventually, we'll have a version of touch theme packages that will be compatible with Cmd's sass generation mechanism, and the good new is that this structure sounds like it's already set up to work in that mode once it becomes available. Unfortunately, we're just not quite there yet with the current set of releases, so this will be the best option available for easy consumption of this component by touch Cmd apps.