You should be able to:
- Be able to identify common ways to debug software and procedures to prevent bugs
- Define the DOM
- Set up event listeners to handle DOM events
- Manipulate the DOM using the DOM API
- Explain how a browser uses HTML, CSS, and JavaScript to display a web page
What technique(s) / tools would you use to debug a program that crashes but gives you an error on a line that you didn't write (ie: from an external dependency)?
Credit: Sarah Zhao
-
Preventative Measures
- check your linter
-
If problem exists in the browser
debugger; Issue: it can be useful, but it can also be in a piece of code you don't even recognize, so you need to decide when to stop walking through functions you and your team didn't write.
-
In general
console.log/console.trace/console.error.
-
Less Useful (in this context)
- read the stack trace ; Since you didn't write this code, the stack trace won't truly help you. The only thing it can help is to possibly figure out what librarry you were using/where in a general location your broken code can be.
-
A Classic Move
- comment out the program, then uncomment piece by piece util it crashes ; This is surprisingly useful if you know that everything worked before you added your batch of code. You can start commenting out certain sections to make sure individual pieces still work, and slowly add on more until it breaks.
-
Toss it in the bin.
- revert to a prior commit ; Just start again.
| correct? | explanation (if applicable) | ||
|---|---|---|---|
| It is a tree | ☑️ | ||
| A single webpage can have any number of DOMs | You can actually create a "new DOM" but there will always be one DOM that renders the page | ||
| It stands for: Document Object Model | ☑️ | ||
| It allows us to use JavaScript to manipulate the document content and structure | ☑️ | ||
| You cannot traverse the DOM from JavaScript, only through the browser's console |
document.querySelector('h1')
Explanation: querySelector returns the first Element within the document that matches the specified selector.