Introducing React ReExt – Sencha Ext JS Components in React! LEARN MORE

Exterminating Bugs in Your Ext JS App

July 1, 2020 121 Views
Show

It was great “seeing” everyone at the webinar last week! I’ve been building Ext JS applications for a long long time and while debugging can be fun, it can be quite challenging at the same time! 

I really enjoyed sharing my personal experience on how to efficiently debugging Ext JS applications. If you missed my webinar — Exterminating Bugs in Your Ext JS Applications — you can watch it on demand

In this short post I am attempting to provide more in-depth answers to some of the many questions asked during the webinar.  If you are interested, here is the tutorial material used for the webinar 

Let’s dive right in. 

Can you provide a classical example which spotlights on the  security aspect of web applications?

My presentation was mainly about debugging. However, security for an Ext JS app is the same as any browser-based application, whether it’s vanilla JavaScript or using a framework. Typically, the user authenticates, the backend issues a token, and that token is sent back to every subsequent request. The backend then inspects the token to make sure it hasn’t timed-out, and to verify what URLs can be accessed. This is the same for any framework.

How can we detect memory leakage in solution?

My presentation covered simple debugging for things like configuration or logic errors. However, Chrome has a lot of powerful debugging tools. Here’s a link to some Chrome Developer Tools documentation on memory leaks:
https://developers.google.com/web/tools/chrome-devtools/memory-problems

Which option should be used to access a component? “id” / “itemid” / “reference”?

For debugging you’re free to use any of those. 

Note that it’s an anti-pattern to use “id” in your own component configurations, but ids are assigned dynamically, so you’re free to use them when debugging. Simply use Ext.getCmp() to get a reference using the id.

For itemId you can use a selector of the form Ext.first(‘parentxtype #childItemId’) — it’s a common and convenient pattern to use the container xtype followed by either the child xtype (if there’s only one) or itemId.

You can also use the reference by using something like the following, which returns the first child under the parent with the specified reference.

Ext.first(‘parentxtype [reference=myreference]’)

Does fiddle come with ExtJS framework that is locally stored or is it only on Sencha’s website?

Sencha Fiddle is only available at fiddle.sencha.com

Could you cover more on performance logs? How can we detect the problem area causing performance hit and how can we tune performance with development tools?

My presentation only covered basic debugging of config and logic errors. However, here are a couple of links that discuss performance profiling using Chrome Developer Tools. https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference
https://developers.google.com/web/tools/lighthouse

Please share the application code through GitHub so we can check best practice ideas!

Check out the tutorial material for the info on application code. You can also contact me at [email protected] with any questions or thoughts.

Could you share the bookmark app?

That’s the last slide in the presentation. I’ll continue to improve it. I also have a colleague working on something similar (and probably better!) — email me at [email protected] if you’d like to be notified when we publish something better.

Missed the webinar?

Watch it on demand today!