Docs Help

Terms, Icons, and Labels

Many classes have shortcut names used when creating (instantiating) a class with a configuration object. The shortcut name is referred to as an alias (or xtype if the class extends Ext.Component). The alias/xtype is listed next to the class name of applicable classes for quick reference.

Access Levels

Framework classes or their members may be specified as private or protected. Else, the class / member is public. Public, protected, and private are access descriptors used to convey how and when the class or class member should be used.

Member Types

Member Syntax

Below is an example class member that we can disect to show the syntax of a class member (the lookupComponent method as viewed from the Ext.button.Button class in this case).

lookupComponent ( item ) : Ext.Component
protected

Called when a raw config object is added to this container either during initialization of the items config, or when new items are added), or {@link #insert inserted.

This method converts the passed object into an instanced child component.

This may be overridden in subclasses when special processing needs to be applied to child creation.

Parameters

item :  Object

The config object being added.

Returns
Ext.Component

The component to be added.

Let's look at each part of the member row:

Member Flags

The API documentation uses a number of flags to further commnicate the class member's function and intent. The label may be represented by a text label, an abbreviation, or an icon.

Class Icons

- Indicates a framework class

- A singleton framework class. *See the singleton flag for more information

- A component-type framework class (any class within the Ext JS framework that extends Ext.Component)

- Indicates that the class, member, or guide is new in the currently viewed version

Member Icons

- Indicates a class member of type config

- Indicates a class member of type property

- Indicates a class member of type method

- Indicates a class member of type event

- Indicates a class member of type theme variable

- Indicates a class member of type theme mixin

- Indicates that the class, member, or guide is new in the currently viewed version

Class Member Quick-Nav Menu

Just below the class name on an API doc page is a row of buttons corresponding to the types of members owned by the current class. Each button shows a count of members by type (this count is updated as filters are applied). Clicking the button will navigate you to that member section. Hovering over the member-type button will reveal a popup menu of all members of that type for quick navigation.

Getter and Setter Methods

Getting and setter methods that correlate to a class config option will show up in the methods section as well as in the configs section of both the API doc and the member-type menus just beneath the config they work with. The getter and setter method documentation will be found in the config row for easy reference.

History Bar

Your page history is kept in localstorage and displayed (using the available real estate) just below the top title bar. By default, the only search results shown are the pages matching the product / version you're currently viewing. You can expand what is displayed by clicking on the button on the right-hand side of the history bar and choosing the "All" radio option. This will show all recent pages in the history bar for all products / versions.

Within the history config menu you will also see a listing of your recent page visits. The results are filtered by the "Current Product / Version" and "All" radio options. Clicking on the button will clear the history bar as well as the history kept in local storage.

If "All" is selected in the history config menu the checkbox option for "Show product details in the history bar" will be enabled. When checked, the product/version for each historic page will show alongside the page name in the history bar. Hovering the cursor over the page names in the history bar will also show the product/version as a tooltip.

Search and Filters

Both API docs and guides can be searched for using the search field at the top of the page.

On API doc pages there is also a filter input field that filters the member rows using the filter string. In addition to filtering by string you can filter the class members by access level and inheritance. This is done using the checkboxes at the top of the page.

The checkbox at the bottom of the API class navigation tree filters the class list to include or exclude private classes.

Clicking on an empty search field will show your last 10 searches for quick navigation.

API Doc Class Metadata

Each API doc page (with the exception of Javascript primitives pages) has a menu view of metadata relating to that class. This metadata view will have one or more of the following:

Expanding and Collapsing Examples and Class Members

Runnable examples (Fiddles) are expanded on a page by default. You can collapse and expand example code blocks individually using the arrow on the top-left of the code block. You can also toggle the collapse state of all examples using the toggle button on the top-right of the page. The toggle-all state will be remembered between page loads.

Class members are collapsed on a page by default. You can expand and collapse members using the arrow icon on the left of the member row or globally using the expand / collapse all toggle button top-right.

Desktop -vs- Mobile View

Viewing the docs on narrower screens or browsers will result in a view optimized for a smaller form factor. The primary differences between the desktop and "mobile" view are:

Viewing the Class Source

The class source can be viewed by clicking on the class name at the top of an API doc page. The source for class members can be viewed by clicking on the "view source" link on the right-hand side of the member row.

Ext JS 6.2.0

Quick Start
Guides
API
modern
classic
top
Guide applies to: classic & modern

Getting Started

Getting started with Ext JS 6 and Sencha Cmd 6 couldn't be easier. With a single command, you'll have a fully functional "universal" starter application that can be run on a local web server.

A "universal" application contains a core set of stores, models, and controllers, while presenting two different sets of views by way of the two toolkits: Classic, and Modern.

The Classic toolkit contains the traditional pieces of the Ext JS codebase that supports legacy browsers, tablets, and touch screen laptops. The Modern toolkit contains a touch-friendly codebase that supports modern browsers, tablets, and phones.

Let's get started!

  1. Download and Install Sencha Cmd 6

  2. Download and unzip the Ext JS SDK

  3. Open your terminal or console window and issue these commands:

     sencha -sdk /path/to/extjs/framework generate app AppName path/to/app
     cd /path/to/app
     sencha app watch
    

Note: For the purposes of this walkthrough, AppName will be MyApp and path/to/app will be ./MyApp.

That's it. You've created an application and deployed a server. Now navigate to http://localhost:1841 or your native localhost. You can now view your newly generated Ext JS 6 application.

Sencha Cmd is now monitoring your application for changes. You will see "Waiting for changes...", which is an indication that your application is up to date. As you make changes and save files you will see other messages printing, but these will end shortly with another "Waiting for changes..." message. This cycle usually takes a few seconds, so be sure to allow enough time between file saves and hitting Reload in your browser.

Note: If sencha app watch fails to pick up your changes for any reason, you can simply stop (CTRL + c) and restart app watch.

Note: _If you're curious about what the above steps entail, you may want to check out our Introduction to Sencha Cmd Guide._

Next Steps

As mentioned above, Universal applications are made up of three important areas:

  • Shared app area (most suitable for stores, models, and controllers). This area can be found in the app folder in your application's root.
  • Classic app area (views and logic specific to the classic aspect of your application). This area can be found in the classic/src folder in your application's root.
  • Modern app area (views and logic specific to the modern aspect of your application). This area can be found in the modern/src folder in your application's root.

It should be noted that this small application illustrates a huge number of features in Ext JS. There is not enough space to discuss everything in-depth, so we will do a small overview for the pertinent bits. We'll make sure to point you to more in-depth information for each topic when possible.

Let's begin by evaluating the Main classic view found in MyApp/classic/src/view/main/.

Classic

The Main classic view will appear anytime someone is using a desktop browser or a tablet, unless otherwise specified in your build targets.

Using your favorite IDE or text editor, open MyApp/classic/src/view/main/Main.js. This is the main entry point for our classic application. It's also the container that houses our tabpanel and its four tabs. Additionally, you'll see that the first tab includes our grid class.

Let's walk through tabs.

Tabs

TabPanels can be used similarly to standard Panel for layout purposes, but they also have special support for containing child Components (items). These items are managed using a Card layout manager, and displayed as separate tabs.

Tabs typically default to horizontally residing at the top of your item content. However, in this application, we have gotten a little clever with the tabs.

You may notice that our tabs don't look like traditional tabs. That's because we've created a custom UI for them.

UI Styling

Every component in the Ext JS framework has a ui configuration that defaults to default. This property can be changed to allow components in your application to have different styles.

Most Ext JS components have SASS @mixin's that allow you to quickly generate new UIs. These include: Ext.panel.Panel, Ext.button.Button, Ext.Toolbar, Ext.window.Window, and many more.

Let's open our tabpanel's custom UI and take a look at what's being done. You can find your tabpanel UI definitions here:

`classic/sass/src/view/main/Main.scss`

As you can see, creating UIs is simple. Simply call the associated @mixin for the component for which you want to create a UI.

@include extjs-tab-panel-ui(
    $ui: 'navigation'
);

All of the variables within the @mixin can be modified in any way you like.

You then attach the UI to your component like so:

ui: 'navigation',

We'll discuss styling your application with SASS in greater detail below.

Responsive

You may have also noticed that we added the Responsive plugin to the tabPanel and the tabConfig.

// TabPanel    
responsiveConfig: {
    tall: {
        headerPosition: 'top'
    },
    wide: {
        headerPosition: 'left'
    }
},

// Tab Config
tabConfig: {
    plugins: 'responsive',
    responsiveConfig: {
        wide: {
            iconAlign: 'left',
            textAlign: 'left'
        },
        tall: {
            iconAlign: 'top',
            textAlign: 'center',
            width: 120
        }
    }
}

This plugin allows us to set rules that modify the tabpanel and tab text/glyph positions based on the width and height of the viewport. In this case, if you make the browser window less wide than tall, the tabpanel will move to the top of the screen and the tab text and glyphs will reposition.

If the viewport is wider than tall, the tabs will appear on the left and adjust the tab text/glyph positions appropriately.

You can read more about the responsive plugin and building your application for multiple environments here.

You may notice that there's no hard-coded data in tabs 2, 3, and 4. That's because we're binding data from a ViewModel.

View Models and Data Binding

Together, View Models and Data Binding
allow you to do more with less code and write in a much more declarative style.

A View Model is a class that manages a data object. It then allows components interested in this data to bind to it and be notified when it changes. The ViewModel, like ViewController, is owned by the view that references it.

For the most part, any config that may be "set" with a setter method, can be bound to the data in the ViewModel. For this example, we'll utilize setHtml() and setTitle().

Let's take a look at the following lines:

// View Model Declaration
viewModel: 'main',

// Binding to header's title
header: {
    title: {
        bind: {
            text: '{name}'
        },
        flex: 0
    }
},

// Binding to tab's HTML config
{
    title: 'Users',
    iconCls: 'fa-user',
    bind: {
        html: '{loremIpsum}'
    }
}

You can see that data is bound from the universal ViewModel (app/view/main/MainModel.js) to the tabs and app title. The data in the ViewModel is set statically, but in most cases, this would be generated via proxy.

Check out our ViewModels and Data Binding Guide for more information.

Grids

Next, let's look at the Ext.grid.Panel by opening MyApp/classic/src/view/main/List.js.
List.js contains the grid that loads within the first tab of your Main tabpanel. With this minimal amount of code, we've created a fully functional grid. By default, each column is sortable and will toggle between ASC and DESC sorting when you click on its header. Each column header is also re-orderable by default, and each gains a drop-down menu with options to hide and show columns.

Not only that, but it's incredibly easy to configure each column independently.

Let's dissect a couple of the grid configs a little further:

Store

As you can see, we are setting store to a type of personnel. If you look carefully, you'll probably notice that there isn't a store definition anywhere in the classic area. That's because this store lives in the universal area, app/store/Personnel.js. We have placed the store here so that the Classic grid AND the Modern grid can share the same store and data.

In a real world situation, the above store would have a proxy with a url property allowing the proxy to pull information from a server. We are keeping the data in-line in this example for the sake of visualization. However, most situations would not call for having in-line data.

Listeners

You'll also notice that the Listeners object contains a select event that calls 'onItemSelected'. Again, you won't find a view controller with that logic in the Classic area. You will find MainController.js in the universal section because both Modern and Classic's grid share the select event and react to it similarly.

If you haven't already, let's open app/view/main/MainController.js.

You'll see some very basic logic:

onItemSelected: function (sender, record) {
    Ext.Msg.confirm('Confirm', 'Are you sure?', 'onConfirm', this);
},

In both our grid and the Modern toolkit's grid (more in a minute), we are handling the select event. The controller logic handles both components’ select events identically.

We'll talk more about universal controllers further down the page.

We've covered most of the meat and potatoes from the Classic toolkit. Let's move on to the Modern toolkit.

Modern

As with Classic, let's begin by reviewing MyApp/modern/src/view/main/Main.js.
This is the main entry point to our Modern application. In much the same fashion, you'll notice Main is a container that houses our tabpanel, and its four tabs. Additionally, you'll see the first tab includes our Modern Grid.

Tabs

Modern toolkit's tabpanels are a great way to allow the user to switch between several views that are all fullscreen. Each Component in the TabPanel gets its own Tab, which shows the Component when tapped. Tabs can be positioned at the top or the bottom of the TabPanel.

You'll see many similarities between this view and the Classic view. For instance:

  • Shared ViewController
  • Shared ViewModel
  • Bound Configs

Modern Grid

The Modern Toolkit includes a lightweight grid that is optimized for touch devices. The Modern grid makes it easy to fetch, sort, filter, and edit large amounts of data on touch devices. It’s also simple to configure and customize any column using column renderers.

As with the Classic Toolkit's grid, you can see a shared universal store and a listeners object that is capturing the select event.

Universal

We've touched on all of the code sitting within the universal section of our application. That said, you'll need to make sure you're careful and consistent when utilizing this space. At this time, you should avoid placing application views themselves in the universal section. If you require or make reference to a class that does not exist in one toolkit or the other, you'll encounter errors when building your application.

This area should generally be reserved for things found in the core of both toolkits.

  • ViewControllers
  • ViewModels
  • Models
  • Stores

Going forward, we are working towards component parity so that sharing view terminology will be less of a concern in the future.

Lastly, you'll want to be sure that any events you're trying to utilize have the same parameters and are triggered with the same intent across both toolkits.

Change Themes

Now let's focus on the look and feel of the application. The default theme (Triton) is generated with every new application unless told otherwise. That said, it's incredibly easy to swap themes once your application has been created.

Let's try out the Ext JS Crisp theme.

All you need to do is open your app.json file in your application root and update the theme property from:

"theme": "theme-neptune"

to:

"theme": "theme-crisp"

Once watch has completed, refresh the page and you should see that your application has gotten a face-lift.

Styling Your Application

On most occasions, you'll need to customize the look of your application beyond the capacity of a default theme. Your application looks pretty good, but blue just isn't working. Let's try and get those active tab colors to be more unique to our application.

Note: The following steps will style the classic views within your application. In the near future, Ext JS 6 will be improved to allow for theming the views of both toolkits within the same application.

You can easily and efficiently style your application by creating and modifying SCSS files.

SCSS (Sassy CSS) is a syntax of SASS, which allows you to add nested rules, variables and mixins to your design code. These new additions are then processed and converted to traditional CSS files for your application's consumption.

To see a list of global SCSS variables, check out this page from our API docs: Global_CSS

Individual components also have specific SCSS variables for you to change. For instance, you can view specific Panel SCSS variables by visiting the Panel API page and scrolling to the “CSS Variables” section: Ext.panel.Panel

If you open up your classic/sass/src/view/main/ folder, you'll see a file called Main.scss. These folders and files will need to be added manually as needed. For each class in your application, Sencha Cmd checks for a corresponding SCSS file in sass/var/ for variables, and sass/src/ for rules.

These files will be picked up by sencha app watch when you add them.

Let's go ahead and look at our Main.scss file.

As you can see, we have some specific SCSS rules set up for the main view. The top panel is set by the following line:

$ui-header-background-color: $base-color,

You have a couple of options here in terms of the scope of your color change. If you
only want this one piece to not be blue, you can explicitly set it to a specific color like so:

$ui-header-background-color: #87BD3E,

Once the change is picked up and processed by watch, you can refresh your page and see that your active tab color is now green (#87BD3E).

However, if you want to replace blue for green across the entire application, you can change the value of $base-color. In order to do this, create an SCSS file for your global rules in the following location:

classic/sass/etc/all.scss // all.scss may contain any SASS / CSS rules

Once you've created your file, you can add a new $base-color declaration that will override the app theme's $base-color value. In this case, let's do the same green.

$base-color: #87BD3E dynamic();

After your application is refreshed, you should now see that many components are that color of green.

Wrap Up

Now you see how easy it is to get an application up and running using Ext JS and Sencha Cmd. Make sure to check out the API docs for all of the Components and classes that we explored throughout this walkthrough.

Ext JS 6.2.0

Ext JS
Sencha Test
Cmd
Sencha Themer
GXT
IDE Plugins
Sencha Inspector
Architect
Sencha Fiddle
Touch
Offline Documentation

Sencha Test

2.0.0 1.0.3

Cmd

Cmd

Sencha Themer

1.1.0 EA 1.0.2

GXT

5.x EA 4.x 3.x

IDE Plugins

IDE Plugins

Sencha Inspector

Sencha Inspector

Sencha Fiddle

Sencha Fiddle

Offline Documentation

Offline Documentation