You should be able to:
- Be able to identify common ways to debug software and procedures to prevent bugs
- Define the DOM
- 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)?
console.log/console.trace/console.error- In general
- check your linter
- Preventative measures
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.
- comment out the program, then uncomment piece by piece util it crashes
- A classic move
- 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.
- read the stack trace
- Less useful in this context, specifically
- Since you didn't write this code, the stack trace won't necessarily 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.
- revert to a prior commit
- Toss it in the bin and just start over.
- Not really recommended.
| True? | 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:
querySelectorreturns the firstElementwithin the document that matches the specified selector.