Mats Bryntse
Founder, @bryntum
Dealing with javascript errors in SPAs
Slide 2
Slide 2 text
Who is Mats Bryntse?
• From small village Lund, live in Stockholm
• Founder of Bryntum
• Scheduler, Gantt + Kanban UI components
• Web dev tools (testing, error monitoring)
• @bryntum
• www.bryntum.com
Slide 3
Slide 3 text
Error handling 101
Slide 4
Slide 4 text
Javascript error basics
• Javascript errors are unhandled exceptions in your code base
• Or in the frameworks you use
• Doesn’t matter where errors happen, poor user impression
• With JS codebases in the size of MBs, cannot ignore error handling + logging
• Good news - it’s easy
Slide 5
Slide 5 text
When a web site error happens, you as a dev see…
Slide 6
Slide 6 text
What does the user see when there is a JS error?
Slide 7
Slide 7 text
Nothing
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
Two scenarios for the end user:
• Error is captured by you. User notified
• Or……
• Nothing happens for user, will probably try same action again.
• If you’re lucky, user will contact you
✉ ✊
Slide 10
Slide 10 text
Live demo of an error
Slide 11
Slide 11 text
The error debugging process
Slide 12
Slide 12 text
Bug life cycle
Fix
Occurrence ℹ
Investigate
Reproduce
Report
✅
Slide 13
Slide 13 text
Developers need to be “in context” to fix a bug
Slide 14
Slide 14 text
Web debugging context wish list
1. Error message
2. File / line number
3. Call stack
4. Screenshot
5. Step by step description
6. Log of user / browser session activity
7. Seeing the user reproduce the error
8. Live breakpoint in production environment
9. Live breakpoint on my localhost, in my fav browser
Slide 15
Slide 15 text
Once you have breakpoint, it’s all downhill!
Slide 16
Slide 16 text
Error
at Object.module.exports.request (/home/vagrant/src/kumascript/lib/kumascript/caching.js:366:17)
at attempt (/home/vagrant/src/kumascript/lib/kumascript/loaders.js:180:24)
at ks_utils.Class.get (/home/vagrant/src/kumascript/lib/kumascript/loaders.js:194:9)
at /home/vagrant/src/kumascript/lib/kumascript/macros.js:282:24
at /home/vagrant/src/kumascript/node_modules/async/lib/async.js:118:13
at Array.forEach (native)
at _each (/home/vagrant/src/kumascript/node_modules/async/lib/async.js:39:24)
at Object.async.each (/home/vagrant/src/kumascript/node_modules/async/lib/async.js:117:9)
at ks_utils.Class.reloadTemplates (/home/vagrant/src/kumascript/lib/kumascript/macros.js:281:19)
at ks_utils.Class.process (/home/vagrant/src/kumascript/lib/kumascript/macros.js:217:15)
“A live breakpoint is worth a 1000 callstacks”
Slide 17
Slide 17 text
Common approaches to error handling
Slide 18
Slide 18 text
• Pros: Cheap
• Cons: Bugs live forever
Do nothing
Slide 19
Slide 19 text
Email ping pong
Slide 20
Slide 20 text
Email ping pong - Enterprise version
Error in web app
Reports to own support Your company
User realises it’s an error
01010
10110
11110
User Dear User,
/Depressed dev.
Can’t reproduce,
need more info.
Sincerely yours,
Slide 21
Slide 21 text
• Pros: None
• Cons: Slow, expensive, demoralizing,
frustrated end user
Slide 22
Slide 22 text
Roll your own logger
Slide 23
Slide 23 text
Roll your own logger
• Pros: Simple, get basic error info. Awareness
• Cons: Lots of code to scan through
Slide 24
Slide 24 text
Using a 3rd party logger
• Pros: Tons of data, call stack, console logs, ajax, user activity.
Enables you to search for the error
• Cons: Slow, tons of data to parse, manual work, code to review
Second generation tools
• LogRocket, SessionStack, Testim
• Generate video
• Manual video recording + feedback collection
• Replay & view the error
• Focus on showing you the bug, not just data gathering
Slide 29
Slide 29 text
RootCause - debugging javascript errors in 2017
Slide 30
Slide 30 text
Sign up here: https://app.therootcause.io
Summing up:
• Don’t rely on users reporting bugs
• Automate your error reporting
• Don’t waste time on end-user email ping-pong
Slide 31
Slide 31 text
Breakpoint
or GTFO
@bryntum
Questions?
@the_rootcause