A case study into the common problems faced by companies when trying to upgrade their legacy Sencha applications. Learn about the benefits of upgrading, the common issues faced and how to avoid them in the future.

1. SENCHA UPGRADES
THE GOOD. THE BAD. THE UGLY.
EVA LUCKHIRAM | ENGINEERING LEAD

3. REASONS WHY COMPANIES DON’T UPGRADE
• Starting all over again
• Stick to what they know
• Time to upgrade
• Can’t afford to invest resources
• New contracts that take priority
• Complex application
• Legacy code
• Their scared!

4. EXAMPLE
• No upgrades for 2 years
• iOS & Android updates
• Customers moved to newest devices
• Features stopped working as they should
• Angry Customers

5. THE GOOD
Reap the benefits
• You don’t pay for it now, you pay for it later
• Powerful new out of the box components
• JS standards and browser compatibility
• Sencha support for the latest version
• Mobile ready
• Sencha tools

6. SENCHA CMD
• Use it!
• Help with future migrations
• Quickly create generate components & apps
• Compile optimised builds
• Reduce application load time
• Fashion & Themer
• Live browser updates without reload
• Helpful error messages

7. SENCHA THEMER
• No dedicated design team
• Strict brand guidelines
• Create styles once and apply to multiple apps
• Use UI’s for specific styles
• Inspect your live app!

9. SENCHA TEST
• Jasmine, WebDriver & Istanbul
• Maintain quality
• Command Line or GUI
• Integrates into CI tools
• Regression Tests
• Test at milestones during the migration
• Less overwhelming when things start to fail

10. • Remove messy code
• Get rid of TODO’s
• Start documenting your code (JSDuck)
• Maintain documentation
• Stick to a Coding Standard
• Same code formatting for all developers
• No bad habits picked up or added

11. THE BAD
Avoid bad practice
• Utilise speed & performance improvements
• Stick to best practice
• Use the Sencha Docs
• Avoid the common pitfalls

12. MONSTER CLASSES
• Unreadable and unmanageable
• Hundred’s of 1000’s LOC
• Harder to migrate
• Hard to debug
• Sencha class structure
• MVVM - organise code based on function
• ViewControllers
• Good for memory management

13. GLOBAL QUERIES
• Ext.ComponentQuery.query
• Is it necessary?
• up() or down() from component
• lighter in process
• Global queries useful for debugging

14. DECLUTTER YOUR DOM
• Proper component use
• Don’t default to panels
• Keep view lightweight
• Improve overall load time
• Create & destroy components on demand

15. THE UGLY
Remove ugly code
• Don’t copy & paste bad code
• Review existing code
• Identify areas of improvement

16. OVERNESTING
• Clutters the DOM
• Be careful how you structure components
• Make use of Sencha layouts
• Don’t wrap everything in a container

17. EXISTING OVERRIDES & CUSTOM COMPONENTS
• Do you still need them?
• Why were they created?
• Are they solved by the upgrade?
• The functions they override may not exist anymore
• Overrides affect all instances of component

18. CODE REUSE
• Simplify your codebase
• Don’t repeat code
• Make use of ViewModels and data binding

19. LEGACY CODE
• Overly complicated logic
• No one understands it
• Culprits no longer at the Company
• Undocumented
• This is a common issue!
• Rework it and make it better

20. doSomething: function (controllerName, actionName, param1, param2, param3, param4, param5, param6, param7, param8, param9, param10, param11, param12, param13, param14, param15) {
var controller = this.getController(controllerName);
controller.init(this);
if (controller !== null) {
if (controller['action' + actionName] !== null) {
controller['action' + actionName](param1, param2, param3, param4, param5, param6, param7, param8, param9, param10, param11, param12, param13, param14, param15);
return true;
}
}
return false;
}

21. QUESTIONS