Meet the sidekicks, Logs and Inspect Entity
The first part of this teardown helped you see how the Error pane can save you hours in debugging and build better internal apps. In this one, let’s meet two seemingly innocuous features that can give you debugging super-powers when used right.
The Logs pane shows you everything logged by Appsmith and, like Errors, in lockstep with the sequence of code execution in your build. Borrowing from the experience of showing logs in general—in the browser console, from a shell, or on your favorite IDE—the Logs pane has four views for specific debugging use cases.
This view shows you all logs timestamped by when we saw them in your Appsmith session. Updated a widget’s property? Wrote a new action to your GraphQL datasource? Ran a JS Object to concat two queries? It all gets logged, including the errors you see in the Errors pane, in a separate view called Error Logs. You will see how that can be useful in a GIF, pun intended.
The All Logs view can be a little overwhelming, though, and a bit of work when you have been at your build for a while. For easier tracking of relevant logs, use one of the three options below.
Everything you learned about the Errors pane applies to this view, too, but there’s more to this view. Here's a likely scenario to show that.
You have a button to reload a table, presumably to refresh the data from your datasource.
You use the Button property, onClick, which runs the query to fetch the latest data into the table.
Your query fails.
- On just the Error pane
- On the Error Logs pane under Logs
The triaging in our example above is especially useful when you have nested queries, several dependent bindings, and a more complex workflow overall.
Set points in your code that you want to log statements at, view tabular data, or see groups for repeated errors.
Automatically tracking all your interactions with Appsmith during build, System Logs show a helpful trail of activity by descending order of timestamp, especially useful when you want to go back in time or pivot from a point of failure to everything that led to it.
They show up for different situations and interactions for the type of entity you are working with.
With widgets, you see a log when you
With actions, you see them when you
With JS Objects, you’ll see system logs when you
Just like errors, system logs are native to entities and have four parts to them.
Logged as your entities are created, updated and deleted, these little breadcrumbs help you track back from when the error occurred to when it was last A-Okay.
Useful during build, the message of the log answers two questions— what were you doing with an entity—creating it, updating it, deleting it—and what happened with your action—success or failure.
Like errors, a system log has two parts to its source—the entity’s name.the type of entity, e.g., SELECT1.TABLE1.WIDGET.
👌🏽 Appsmith Experience plug
Clicking the source from the logs takes you to the associated entity anywhere in Appsmith, be it a widget, a query, or a JS Object. Noice!
This doesn’t always show, but when it does, it can be useful confirmation of a binding working, a query running successfully, or a JS Object executing completely.
Borrowing from a modern browser’s Inspect Element feature, Inspect Entity lets you see incoming and outgoing entities for any widget. These entities can be queries, JS Objects, or even other widgets.
The Inspect Entity pane lets you see dependencies for all your widgets on the canvas, especially useful if you have a medium-complex app with several widgets working off of each other. For example, when you have a parent widget or query that controls bindings on other dependent widgets---call them children widgets---, Inspect Entity can show you all those children when you click the parent and quickly take you to any one of them directly.
In combination with Errors, Logs and Inspect Entity round out the Debugger for several scenarios during build and save you hours in building an app end-users love. Try out the Debugger and let us know how you like it, what it's missing, and what we can improve. Our Discord is the best place for that feedback.
That title is a tongue twister, innit? Almost.
Here’s a meme that isn’t. It’s just the painful truth.
There is no perfect code, so you know debugging is inevitable, but it’s still a chore and is as crushing often times as the meme claims it is.
But, while debugging is inevitable, making it painful is optional, especially when you have the Appsmith Debugger. We have claimed we champion developer experience as many times as we could before without being brazen about it. We think. So, we thought some more and said, “Let’s prove the claim, too.”
In 2021, we shipped the Appsmith Debugger, a set of Chrome DevelTools-like features that have helped you investigate and resolve errors in Appsmith.
We recorded a video for it in a series about the Debugger, talked about it in our docs, and referenced it enough times to make you groan about our obsession with errors. If this is the first you are hearing of it, get on our Discord so we can tell you some more about it.
Browser dev tools are as helpful as a magnet when looking for iron fillings in a pristine haystack. To the untrained eye, they can be downright criminal, too.
Sure, sure, they nest groups of errors and there are separate tabs for the console and the debugger, but meh! There’s a sea of error messages, system logs, console logs, and then there’s you swimming in it.
Before we shipped the debugger, you saw,
The Debugger solved several of those problems.
Available on app.appsmith.com and our self-hosted release images, it can be called by toggling the debug icon—the one that looks like a bug—on the bottom-right corner of your Appsmith screen or with CTRL/CMD +D.
Inside the Debugger, live three panes, Errors, Logs, and Inspect Entity, each with their own uses. In the first part of this two part post, we will break the Error pane down for you and see how it can save you hours over browser dev tools in debugging.
If you would much rather just learn about Logs and Inspect Entity, bookmark this post. We will link to Part 2 in five days. :-)
Logged as your code executes or a value evaluates with your widgets, these little breadcrumbs help you track back from when the error occurred to when last it was A-Okay.
Depending on the error type, you will see a couple different kinds of issues.
This has two parts to it—the entity’s name.the type of entity the troublesome one is, e.g., SELECT1.WIDGET. As is obvious and has been to you, SELECT1 is the entity’s name and WIDGET is the entity type.
👌🏾 Appsmith Experience plug: Clicking the source takes you to the faulting entity anywhere in Appsmith, be it a widget, a query, or a JS Object. Noice!
This is the most helpful part of the message, beginning with Error and ending with a helpful bit of text or a number.
1. The type: Error
2. The string: relation “public.user” does not exit
3. The line number: Position 15
😻 Appsmith Experience plug: Clicking the message will open our in-app docs finder and run a helpful search to show you top docs matching the error.
Response from queries or bindings
This doesn’t always show, but when it does, it can show you helpful responses with query params or evaluated values of data bindings.
Consider two situations we have painfully drawn for you.
You have several queries and widgets on your way to a complete build.
A query fails and returns an error.
Without the Appsmith Debugger
You decide to sift through the browser dev tools sub-window, trying to locate the faulty query in something that looks like ↓.
When you find the first problem query, you’re hoping against hope this is your patient zero.
Most times, though, Murphy’s Law applies.
If you have a friend who’s on Appsmith, you hear them say, “Good morning. Do you have a ready app? No? Try the Debugger. 🙄”
With the Appsmith Debugger
You see all the errors from all the failed queries In the Error pane and nothing else to crowd your investigation.
Don’t remember the query’s name? Pfft! We got it. Click the error message, and go right to the error source.
Trouble troubleshooting? Click the error message and find super-relevant docs in Appsmith’s doc finder.
At the end of it, you save a whole night’s hair-pulls, wake up bright and fresh, sip your coffee, and wonder why some people still use browser dev tools. 🤔 Maybe you should refer them to us.
You have the data from a REST API and the table for your dashboard, but you have left the chart for the very end. You are sensible like that. Charts are tricky things in general.
You get a datatype mismatch error.
Without the Appsmith Debugger
You toggle around the floating EXPECTED STRUCTURE, EXPECTED STRUCTURE - EXAMPLE, and EVALUATED VALUE panes to understand the chart widget’s configuration.
You have a JS Object for the transformation, so you now switch back and forth between the canvas and the JS Editor for each possible fix in the JS code.
With the Appsmith Debugger
Right after you run the transformation, you see the floating-pane-that-we-don’t have-a-name-for-yet show you some red and the Error pane light up with all your errors, timestamped and sequenced by the order of code execution.
You see all the errors from the transformation in one pane with click-actions for each one of them.
Error messages not enough? Click the error and choose, Browse code snippets, and voila! You now now search for the chart + the query right there and see some of our helpful docs.
Made it to here? Your life inside Appsmith is going to change.
Also, this is just part one of this two-part breakdown. What’s next?
Better than post-credits. A whole other movie featuring Logs and Inspect Entity. Meanwhile, here’s a few things you can do.
Until the next Debugger post, Appsmiths.
P.S.: We love you.