Often I get questions from people on how to work efficiently with Sencha while developing in a large team environment.. This question is especially popular for people coming from the Java world, who are familiar with tooling for Java and build processes. I can tell you that it’s not much different for web projects.
This article will discuss the following concepts:
- Source Control
- Sencha Architect for teams
- Editors & IDEs and configuration
- Code analysis tools
- Code reviews
- Test tools
- Build processes
Use a versioning / source control system, to track changes, share your code and save your code revisions as easy backups. A popular Versioning Control tool is Git. (but you can use any versioning tool of choice, such as SVN, CVS, Mercurial, etc…)
Internally at Sencha we use Git & Github. What’s important to know, is that you don’t want to check-in certain files and folders. When you do check in the framework or build folders, keep in mind that there are more changes on Git conflicts, and your code base will become extremely large. To make sure you don’t check-in these files by accident, create a .gitignore file in your project root. I am often using these ignore rules:
# OS generated files #
TIP: Wait? You didn’t check in the frameworks?
Yep. Usually I prefer it to keep my version control light and
clean. (I can tell you how much pain it is, when whole versions of
Ext JS are checked into GIT, and how horrible it is, to use the GIT
client, while it’s slow or crashing down.) - To give you an
impression, the Sencha sdk is over 100 MB. So not checking in the
sdk, means, you will have to generate a new application/workspace,
with the same name space; and copy over the files. TIP:
In case you by accident already committed certain files to Git, you
have to remove them first from Git before ignoring them. For
**git rm file1.txt** **git commit -m "remove
file1.txt"** **git push** In case you have all these
annoying OS generated files in Git, you can remove them like this:
**find . -name '*.DS_Store' -type f -delete**
For more information about Git, checkout:
Whether you are working with Sencha Architect, or just writing code yourself, the best practice would be to define (smaller) classes, and nesting it through xtypes.
Every (view) component, should have its own class, with its own namespace. We don’t need to worry about all these separate files since the Sencha build process (with Sencha Cmd / Sencha Architect uses Sencha Cmd in the background), concatenates and minifies all these classes into one single small file. This improves readability, usability and maintainability but think about it. It also will improve your workflow with source control systems. Cause smaller single files, reduces the change on working with your co-worker on the same file.
When you develop your application with Sencha Architect, and you are dragging your components into the design canvas… …by default all these views will be nested into one single file. (the viewport). You can promote these smaller view pieces to its own classes, so it will become a single class file, which will be nested via its xtype. For example, when you have a viewport with a form with fields, and a component with a template. You can promote the form and the detail component to its own class, by right clicking on the form (or detail component), and select: Promote To Class. After you selected that, you will see a link icon, which indicates that its a linked to its own class. You can start re-using it now too!
Just sometimes, you are both working on the same file. This will result into a merge conflict as soon as you push your version to Git. Git will reject it. I know, this is not nice, but it’s not the end of the world. Always make a backup of your own file, to somewhere else in your file system. You can merge a file. There are various tools available for your editors / IDEs that deal with merging files. Also Git provides a Graphical User Interface which can show the differences. Another solution can be to accept or revert the changes and merge it yourself manually.
TIP: Traditionally we recommend that users do not check in the .architect file or the framework and build folders into their source control systems. In situations where it is necessary to check these into the repository (for example, because you want to run the application directly in your browser after fetching the project), we suggest that you check it in and then add it to the ignore list so that there will not be further conflicts. Last but not least, the overall best solution for working in a team with source control, is communication! It’s just so much easier if you let your co-worker know, on which file / part of the app you are working on!
While writing Sencha code you can use any editor or IDE of choice. Here are a couple of suggestions:
- WebStorm / IntelliJ IDEA from JetBrains - https://www.jetbrains.com/
- _Eclipse_ _-_ https://eclipse.org/
Open source IDE mostly focussed on Java development.
- _Sublime Text Editor_ _-_ http://www.sublimetext.com/
A simplistic editor for code and markup with amazing performance. (Commercial)
- _Brackets_ _-_ http://brackets.io/
A modern simplistic open source editor, great for web development. All of these tools have the ability to use with plugins. For example, plugins to integrate code analysis tools or source control tools.
When you work in a team, what’s most important is that you have your editor/IDE configured the same. Common editor settings are:
- Indent Style: set to tab or space to use hard tabs or soft tabs respectively.
- Indent Size: a whole number defining the number of columns used for each indentation level and the width of soft tabs (when supported).
- Tab Width: a whole number defining the number of columns used to represent a tab character.
- End of Line: set to lf, cr, or crlf to control how line breaks are represented.
- Charset: set to latin1, utf-8, utf-16be or utf-16le to control the character set.
- Trim trailing whitespace: Enable to remove any whitespace characters preceding newline characters and false to ensure it doesn’t.
- Insert final newline: Enable to ensure file ends with a newline or not.
When these settings are out of sync in a team, you can run into many source control conflicts and hard to solve file merges.
- JSLint - http://www.jslint.com/
- JSHint - http://jshint.com/
It is also possible to let Sencha check your code. You can hire a Sencha professional services consultant who can review your code during certain points in your development process. We will check for best practices and see how to optimize your application and performance.
Let’s look into ways how to test your Sencha code:
- Jasmine - http://jasmine.github.io/
Sencha Cmd (and our build processes) run on top of Apache Ant. Apache Ant is a software tool for automating software build processes. It is implemented using the Java language therefore it requires the Java platform. You can write / wire up your own build process and code analysis tools as well. You can write these hooks in the build.xml file (in the project root). The file looks like this:
As you can see lots of code is commented out in here. So nothing is really happening yet. But you can create your own hooks. There’s a Sencha guide online, which contains the available tasks you can use: http://docs.sencha.com/cmd/5.x/advanced_cmd/cmd_ant.html For example, here’s a code snippet I have used to create different build packages, where the folder name of the build contains a date.
For more information, please see: http://ant.apache.org/
When you are building serious enterprise applications you will need to come up with a strategy on how to analyze, test and collaborate your code. As you can see, choosing Sencha empowers developers to design, develop, test and deploy in development teams of any size.