Proposal: Remove logging from Solid UI and add it as a module that is exposed through the data browser
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 153
- Forks
- 46
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 7
Description
I'm currently working on the log module, which exposes a set of methods that mostly do one of three things, depending on the environment:
- if the environment has the document object (e.g. is a browser), it will look for an element with id "status" and append lines to it with time, type of log message and the message whenever the methods are called with a message, or
- if the environment supports console (e.g. Node), it will use console.log to output the messages, or
- do nothing
(The other methods that do not log messages are various configuration methods.)
I think it's weird that the module is dependent on a global element somehow being available, and think it would be better to expose the API through a module that is exposed through the data browser, probably through the DataBrowserContext interface that is made available to views through methods such as render. (It is currently defined in pane-registry.)
Data browser implementations would handle logging differently, but expose the same API. This module could then be passed to methods in Solid UI that requires logging, making the need for log module in Solid UI obsolete.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the existing log module and the DataBrowserContext interface in pane-registry's index.d.ts, then trace how views receive context through methods such as render. Done means Solid UI no longer depends on the log module's global status element and the data browser exposes a common logging API for implementations to handle.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100