Skip to content

Conversation

@RRosio
Copy link
Collaborator

@RRosio RRosio commented Oct 30, 2025


🔍 Preview: https://jupytercon2025-developingextensions--79.org.readthedocs.build/
Note: This Pull Request preview is provided by ReadTheDocs. Our production website, however, is currently deployed with GitHub Pages.

@RRosio RRosio marked this pull request as ready for review October 30, 2025 19:46
Copy link
Collaborator

@mfisher87 mfisher87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking amazing! 🤩


:::{tip} Outcome
By the end of this module, you'll be able to debug JupyterLab extensions using
multiple tools and techniques.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way this is phrased, it seems to me more like a learning objective than an outcome. For outcomes, I think we should phrase in terms of actions participants will take. E.g. they will use multiple tools and techniques to fix bugs in a JupyterLab extension.


Knowing the kind of error you are dealing with is already a solid step forward.

- **Build-time errors vs Runtime errors**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of restructuring this to headers, e.g.?

#### By when they occur

...

##### Build-time errors

Build-time errors happen when you're compiling your TypeScript code or building your extension.
These are often syntax errors, type mismatches or missing/unused imports that don't allow
you to run your code until they are fixed.

Build-time errors appear in your terminal during `jlpm build`.

##### Runtime errors

Runtime errors happened when your extension logic is executing, maybe a failed network request, or an undefined property that you've tried accessing.

Runtime errors show up in the browser console or `jupyter lab` terminal logs after your extension is loaded.

#### By where they occur

With a full stack extension, which includes a server component, it is important to understand which side, server-side or client-side, is causing the error

##### Python server errors

...

##### JavaScript frontend errors

...

When JavaScript throws an error, it gives you a stack trace, a trail showing the path the code took before it crashed. It may seem overwhelming at first, but starting from the top and looking for recognizable file names can help. While the stack trace might show you multiple function calls usually only one or two of those are in _your_ code. The others are likely in other libraries like JupyterLab itself. Finding your line in the code, you can find out where things have gone wrong.

- Minified vs source-mapped traces
Also important, if you see names like `bundle.js:4323`, that's minified code. In development mode with source maps enabled, you'll see actual files names like `Panel.tsx:53`, a much more helpful identifier. Extensions created with the `extension-template` should have source maps enabled already.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should define source maps (glossary?) the first time we use it.

- the HTTT status code (200 is OK/good, 404 means not found, and 500 means server error)
This can be especially useful when debugging issues where data you were expecting is not showing up, or getting an unexpected response from an API call, as getting a 200 response does not always mean you are getting the response you anticipated.

### ⏸️ The Sources Tab: Let's Pause
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice title 🤩

- Keep development environment consistent
Is the extension installed and enabled? Did your latest changes build successfully?

### 🛡️ Prevention is better
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯 💯 💯

// BUG #2: Wrong method name - using 'as any' bypasses TypeScript checking
// This will cause a runtime "is not a function" error when clicked
// Should be load_image(), not refresh()
(widget as any).refresh();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice idea to show turning off typescript checks can make your life harder! Love this. A good lesson to "avoid any at any cost" ;)

@RRosio
Copy link
Collaborator Author

RRosio commented Oct 31, 2025

pre-commit.ci autofix

woops, I missed the merge conflict issue

@RRosio
Copy link
Collaborator Author

RRosio commented Oct 31, 2025

Thanks for your thorough review @mfisher87, I tried to address your comments as best as I could.. please feel free to let me know of any other changes you'd recommend!

@mfisher87
Copy link
Collaborator

woops, I missed the merge conflict issue

Sorry about that, I should have waited a bit longer :X

Copy link
Collaborator

@mfisher87 mfisher87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking really great! I'm not sure what to do about the broken term references offhand. I can try playing with it tomorrow. I think it'd be great to get this merged whenever you feel ready!

|------------|---------------|-----------------|
| **Build-time** | Terminal (`jlpm build`) | During compilation |
| **Runtime (Frontend)** | Browser console | After extension loads |
| **Runtime (Backend)** | `jupyter lab` terminal logs | After extension loads |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love this matrix 🤩


### Elements/Inspector Tab

Sometimes, the best tool is {term}`print debugging <Print debugging>`, which is like a print statement for the browser console, using a simple `console.log()`. Walking through your changes and adding a logging statement to verify/inspect data, or ensure your code reaches certain logic can be quick and effective.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why this term reference isn't working. It looks right to me!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching this Matt! It turns out I added these terms after the closing ::: of the glossary block 😅

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahhhh. That makese sense now :)

Co-authored-by: Matt Fisher <[email protected]>
@RRosio
Copy link
Collaborator Author

RRosio commented Oct 31, 2025

With these final updates I think this is okay to merge! Thanks again for the reviews @mfisher87!

@RRosio RRosio merged commit ec6f011 into main Oct 31, 2025
2 checks passed
@RRosio RRosio deleted the debug-updates branch October 31, 2025 04:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants