All Enyo controls have two published properties to aid in styling: style and classes. These two properties correspond to an HTML element’s style and class attributes. The style property can be used to apply a specific style to a single control. To work with the classes property, you must add CSS classes to a style sheet. In general, it is better to use classes in an app for two reasons: a component is more reusable if a style is not embedded within it and by using a CSS class you can modify the style from a single place.

Enyo provides applyStyle() to update an individual style and addStyles() to add styles onto the existing styles of a control. We used the applyStyle() function in the traffic light sample at the start of the book. Passing a null as the second parameter to applyStyle() removes the style. For upating classes, Enyo provides addClass(), removeClass(), and addRemoveClass().

Each Onyx control includes one or more classes. It is possible to override some (or all) of the default styling by overriding those styles in your CSS file. One simple way to discover the class names to override is to use your browser’s inspector to see what classes are applied to a particular control. You can then use those classes to override the way that control looks everywhere in your app. The following image shows the Chrome inspector output of the Onyx sample from Chapter 3:

The Onyx button has, among its classes, onyx-button. If we want to override the styling on all the buttons in our app without having to manually add a class to each one, we could write our own CSS rule for onyx-button:

.onyx-button {
    background-color: cyan;
}

In general, you will need to use a CSS selector that is more specific than the styles in the Enyo CSS. One method is to add a base class to your app component and then use that in combination with your CSS selector. In the Onyx sample, we cannot override the background color of the actual input control without a more specific selector:

.myapp .onyx-input {
    background-color: tomato;
}

In general, you’d actually style the input decorator rather than the input.

You could, of course, simply go into the Onyx library directory and directly edit the CSS file. Knowing that app developers would want to do this, the Enyo developers provide LESS files for generating the CSS that Onyx uses. LESS provides a programmatic approach to creating CSS while keeping most of the flavor of CSS. In order to compile LESS you will need to have Node.js installed and it helps to be working on a Bootplate project (see Appendix A).

LESS files can be found in the css directory of the Onyx library, along with a previously compiled CSS file. Of particular interest is the onyx-variables.less file, which contains some common settings used throughout the library. Here’s a sample from that file:

/* Background Colors */
/* ---------------------------------------*/
@onyx-background: #EAEAEA;
@onyx-light-background: #CACACA;
@onyx-dark-background: #555656;
@onyx-selected-background: #C4E3FE;

@onyx-button-background: #E1E1E1;

By overriding a particular variable, we can affect a wide range of Onyx styles. If you want to create your own overrides, you can modify your app as follows:

To change all onyx buttons to lime green, you could place the following where variable overrides go:

@onyx-button-background: lime;

For more information on LESS, see the LESS website. For more information on theming Enyo, visit the Enyo UI Theming page.

We covered some of the great layout features that Enyo offers in Chapter 4. Even with these features, things can turn out wrong. One common problem app developers experience is failing to provide a height to List or Scroller components. Without a height, these elements will end up invisible. Providing a height or including them within a fittable layout can solve that issue. Fittables themselves can cause problems. Forgetting to assign fit: true to one and only one of the components of a fittable component can lead to rendering issues as well.

Sometimes things just end up in the wrong place or have the wrong style. A quick way to see what has happened is to use the DOM inspector in your browser to see what styles have applied to the elements in question. Sometimes, an issue such as CSS precedence caused the problem. It can also help to see if a component rendered at all or if it’s hidden somehow. Other times, it can help to add !important to a style.

Bugs are unavoidable. Fortunately, there are lots of ways to squash them. One of the best ways to detect code errors is to keep the JavaScript console open while testing Enyo apps. If there’s an error or typo in your code, it can cause strange problems. Seeing errors as they occur really helps in trapping the problem.

Enyo apps can also write to the JavaScript console with the info(), warn(), and error() functions on the enyo object. In addition, every Enyo kind can call this.log() to send output that includes the kind’s name and the name of the function that issued the log message.

Sometimes a passive approach to debugging a problem isn’t enough. In these cases you can set breakpoints in your code and step through functions that are misbehaving. A handy trick that is supported by the major browsers is putting the debugger command into code you want to inspect. When the browser reaches that code, it will stop and allow you to inspect the state of the app. Just remember to remove that command before publishing your app!

Once you’ve identified a place in the code that you want to inspect, it’s easy to see all the components belonging to a component. this.$ will contain a hash of all the owned components. Also, enyo.$ contains a hash of all named components in your app. You can easily walk through these by inspecting deeper and deeper into a kind.

jsFiddle Debugging

There’s no doubt that jsFiddle is a great environment for quickly testing ideas. It does have some drawbacks though. Among them is that debugging can be a little more difficult and there aren’t a lot of options for working with complex apps. jsFiddle runs your code in an iframe. Because the code you are executing gets reloaded into the iframe each time you click Run, it can be a little tricky keeping breakpoints in line.

Using the debugger command mentioned previously can be helpful, as can using the Inspector window that shows you active source files. The source for your app will be launched from fiddle.jshell.net and will be in-line with the HTML source for the page. If your app does not appear to be working at all, check the code wrap settings at the top to make sure you have selected onLoad and the correct framework:

If you have the wrong settings, you may see the following error message:

Uncaught TypeError: Cannot read property 'className' of undefined

In its most basic form, the globalization library handles string substitutions. Substitutions are performed using the $L() global function. At run time, the $L() function searches for an appropriate translation file for the user’s locale (or the locale you set manually) and then attempts to locate the string that was passed in as the first argument. If a match is found, the translated string is used. If not, the original string is used.

Translation files should be placed in the assets/resources directory of your app. Each translation should be in its own JSON file. Translation files are named starting with language and optionally adding country code and variant. For example, a Canadian English translation file would be named en_ca.json. Such a file might look like this:

{
    "Click": "Click, eh?"
}

App developers can add some extra polish to their apps by correctly formatting information for the user’s region. The globalization library includes modules to format names, phone numbers, dates, times, and more. For more information on the countries supported by these functions, please refer to the localization documentation page. The name, phone, and address modules included with g11n are not loaded by default. The following example shows some of the basic routines for formatting these items:

enyo.kind({
    name: "G11nSample",
    components: [
        { name: "date" },
        { name: "number" }
    ],
    create: function() {
        this.inherited(arguments);
        var dateFmt = new enyo.g11n.DateFmt({ date: "short" });
        this.$.date.setContent(dateFmt.format(new Date()));
        var numFmt = new enyo.g11n.NumberFmt({ fractionDigits: 1 });
        this.$.number.setContent(numFmt.format("86753.09"));
    }
});

new G11nSample().renderInto(document.body);

Two Onyx components are locale-aware: DatePicker and TimePicker. If the globalization library is loaded, they will use the current locale to format their contents. If the library isn’t loaded, then they will default to the US format.