When you're developing custom plugins in the Private Plugin editor, a few paradigms might lead to subtle bugs:
how Polling URLs work
building custom form fields
One thing that shouldn't feel "new" is Logs. TRMNL offers a couple utilities to improve your plugin development workflow.
JavaScript Logs
From the Markup Editor, click to expand the JS Logs dropdown beneath Your Variables.
This is useful for debugging client-side logic, and is similar to cracking open the Developer Console in a modern browser.
In addition to console.log() style output however, TRMNL will attempt to decorate these logs with a level of severity.
The example above showcases 3 severity levels - default, warn, error.
default: white text, includes your own debuggers and Framework Modulations
warn: yellow text; actionable status is up to you
error: red text; includes
error,onerror,unhandledrejection, andfetchprefixes
Plugin Logs
For a firehose of server-side logs, enable Debug Logs from the plugin's settings page.
After activating, a live stream of logs will be enabled for 24 hours. This limits your data exposure to TRMNL and keeps our storage lean.
Now you may visit your Logs, either from the Markup Editor > View Logs, or from your Device's settings page (top right dropdown > gear icon) > Logs.
Server-side log examples:
API failures to your Polling URL(s)
Image generation exceptions
Server hiccups, e.g. if a screen is generated during a deployment
Liquid
filtersyntax errors (see more)
If you have any questions or want to recommend another log type, create an #ideas thread inside the Developer-only Discord (link in your Account tab).