Skip to content

[improvement-854] Added variable debug message functionality for#864

Open
denete wants to merge 5 commits intoaccius:Stagingfrom
denete:improvement-854
Open

[improvement-854] Added variable debug message functionality for#864
denete wants to merge 5 commits intoaccius:Stagingfrom
denete:improvement-854

Conversation

@denete
Copy link
Copy Markdown
Contributor

@denete denete commented Apr 2, 2026

What does this PR do?

Added variable debug message functionality for messages sent to the console. This overrides current console.* and also provides for future scoped logger.* functionality.

Type of change

  • Bug fix
  • New feature
  • Performance improvement
  • Refactor / code cleanup
  • Documentation
  • Translation
  • Map layer plugin

How to test

(Notes on the usage of querystring values are included in src/debug/README.md)

  1. Open the JS console
  2. Note that no console messages show once this has loaded in the app
  3. Add query string to URL and verify the different levels of console output

Examples:

?log=none
?log=error
?log=warn
?log=info
?log=debug
?log=all

Checklist

  • App loads without console errors
  • Tested in Dark, Light, and Retro themes
  • Responsive at different screen sizes (desktop + mobile)
  • If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
  • If adding an API route: includes caching and error handling
  • If adding a panel: wired into Modern, Classic, and Dockable layouts
  • No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
  • No .bak, .old, console.log debug lines, or test scripts included

Copy link
Copy Markdown
Owner

@accius accius left a comment

Choose a reason for hiding this comment

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

PR Review — Debug Logging System

Hey Dee, thanks for tackling #854 — this is a good direction. A few things to address before merge:

Bug: Scoped logger fights its own console override

logger.js calls console[level](...) — but consoleOverride.js already replaced those with noops. So if the log level silences console.info, then logger.info('MyScope', ...) is also silenced even when the scope matches.

Fix: The logger should use the saved originalConsole references instead of the overridden console.* methods. Either export originalConsole from consoleOverride.js, or pass it into createLogger().

Bug: Level index mapping is off

consoleOverride.js uses two arrays that don't align:

const order = ['error', 'warn', 'info', 'log'];              // 4 items
const allowedIndex = ['none', 'error', 'warn', 'info', 'debug', 'all'].indexOf(config.logLevel);  // 6 items

The comparison index > allowedIndex compares positions in two different-length arrays with different semantics. For example, log=warn gives allowedIndex=2, which would allow order[0] (error) and order[1] (warn) but also order[2] (info) — that shouldn't be shown at warn level.

Default log=none silences errors

With no query params, all console output is suppressed including console.error. In production, this means real errors are invisible unless someone knows to add ?log=error. Recommend defaulting to warn or error so problems are always surfaced — devs can use ?log=none explicitly if they truly want silence.

Unused hooks and config

useFeature, useDebugFlag, useRole, useForcedState and the corresponding config fields (features, disable, debug, role, state, perf) are parsed but nothing consumes them. I'd prefer to ship only what's needed now (log level + scope) and add these when there's a use case — keeps the surface area small.

No existing code migrated

This adds the framework but none of the existing console.log calls are converted. The only runtime effect right now is silencing all output. Would be good to see at least a few noisy components migrated as proof-of-concept — maybe the ones that originally motivated #854.

Looks good

  • Clean separation: config parsing, logger, console override, React context
  • Scoped logging is a nice idea for isolating component output
  • Query param approach is zero-config for end users
  • Good README documentation

@denete denete force-pushed the improvement-854 branch from 5bfccb0 to 5c82492 Compare April 3, 2026 15:43
@denete
Copy link
Copy Markdown
Contributor Author

denete commented Apr 3, 2026

@accius All comments addressed.

Copy link
Copy Markdown
Owner

@accius accius left a comment

Choose a reason for hiding this comment

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

Thanks for the update Dee — the core logic in consoleOverride.js and debugConfig.js is clean and well-structured. A few things to address:

DebugProvider should be a plain function call, not a component

DebugProvider calls overrideConsole() on every render — including StrictMode double-renders and any re-render of the tree above it. Since it doesn't use any React features (no state, no context, no effects), it should just be a direct call in main.jsx before the React tree mounts:

import { getDebugConfig } from './debug/debugConfig';
import { overrideConsole } from './debug/consoleOverride';

overrideConsole(getDebugConfig());

ReactDOM.createRoot(document.getElementById('root')).render(...)

This avoids re-execution on renders and removes the misleading "Provider" pattern. DebugProvider.jsx can be deleted entirely.

console.debug is not overridden

Some libraries use console.debug — it will leak through regardless of the level setting. If the goal is to silence noisy console output, this is a gap worth closing.

Minor

  • The README is a nice touch 👍
  • The level map and method map in consoleOverride.js are well done

@denete denete force-pushed the improvement-854 branch from 08274a8 to 337af96 Compare April 5, 2026 19:43
@denete
Copy link
Copy Markdown
Contributor Author

denete commented Apr 5, 2026

Updated with feedback from PR comment.

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.

2 participants