Fashionable ExtJS and Web Services

ExtJS 6 was released at the end of June, and one of the nicest new features in it is a change to their CSS tooling – they’ve replaced Compass with a JavaScript-based implementation of SASS called Fashion. One of the neatest features is “Live Update” – this takes the traditional ‘watch’ approach one step further, and instead of just rebuilding your CSS when you change a SCSS source file, it updates the CSS inside the running browser, without needing a page refresh! This is just awesome, and not something I’ve seen before in my (admittedly limited) experience with web development tools.

But there’s just one problem… you have to use the embedded web server started with the sencha app watch command. Which is fine if all you’ve got is a webpage, but if you’re dealing with web services (as so many web apps do), it’s a bit restricting – at least if you don’t want to configure your app or server to allow cross-site scripting.

But Live Update is too awesome to forego! What to do?

How Does Live Update Work?

Live Update works in two ways:

• it brings in some extra JavaScript – fashion.js and sass-compiler.js. These bring in the necessary “smarts” for the browser to compile SCSS source files into CSS in-memory.
• it also polls periodically to an update servlet running in the sencha app watch web server. When that server detects changes, the update servlet will provide the changed files to the browser the next time it is polled.

These services are provided off ~cmd and ~sass paths, so it’s highly unlikely to conflict with anything you’ve got set up in your app. Unfortunately, it’s not configurable, so if it does conflict, your only solution is either to change your app or patch the sencha-fashion extension.

So How Do You Solve The Problem?

I run my web app out of a Tomcat server (well, Pivotal tc Server, but close enough), to which I deploy both my backend Java web apps, and the raw unpackaged front-end code (which is a single very small HTML file, lots of JavaScript, and a large chunk of SASS packaged as a custom theme). This lets me use ExtJS in a development mode readily enough. But in this setup, I don’t have the Fashion Live Update support.

But the Fashion Live Update is implemented via normal HTTP calls. So I add a WEB-INF folder to my unpackaged front-end code, and installed a proxy servlet¹ to redirect requests to ~cmd and ~sass over to the sencha app watch server running on a different port. This was simple and effective.

This approach, if not the exact solution, is also applicable to other environments, such as .NET programming, or if you’re using a front-end such as Apache or nginx to serve up Ruby, PHP, or Node.

Standalone Pages

Flushed with the success of getting Live Update to work inside my app, I then went to put it into my test pages. These are standalone HTML pages that use ExtJS as a normal library, and aren’t packaged by Sencha Cmd, which bring in unit tests written in Jasmine. (The pages themselves are generated from the unit test files, using a template). Because they don’t use the generated bootstrap.js file, they don’t bring in Fashion by themselves.

All I had to do, though, was add the imports to the page template, and then re-generate:

<script type="text/javascript" src="/~cmd/extensions/sencha-fashion/fashion/fashion.js"></script>
<script type="text/javascript" src="/~cmd/extensions/sencha-fashion/sass-compiler.js"></script>

I then accessed the test pages via the sencha app watch server, instead of going via Apache as I had before. With that, the test pages started to load in the SASS files, and I could do live editing of my SCSS files and see the results reflected within a couple of seconds.

(The includes are fail-safe; if they can’t be found – e.g. inside my automated test runner, or if I go via Apache instead, it just falls back to the previously generated CSS, and I get two 404 errors)

Final Thoughts

I’m still amazed at how neat this is. My biggest² gripe, by far, with ExtJS has been with how annoying it is to work with a custom theme – the tooling support wasn’t good, it would swallow syntax errors without reporting anything, and the turnaround time was really annoying, seeing as how you need to refresh the page. (That may not sound like much, but in a web app where it can take a minute or two to get back to the state you had before refreshing, it’s a big overhead). This, however, removes a lot of that drudgery. Now all I need to do is actually become decent at using SASS and CSS to style my pages. 🙂