tldr; Create an interactive console for use when developing. Instead of being a log of everything that happens on the server, it would group information by what you are more liking to care about.
This was discussed on a recent live stream (54:58) and at a contributors meeting (51:24)
The Problem
When running donejs develop
in your console you will see a log of all activity that happens on the server. This could be:
- Warnings generated within canjs.
- File changes that cause a live-reload event.
- Errors when you do a typo.
And many more. It's not very attractive and looks like this:
![screen shot 2017-09-22 at 9 14 20 am](https://user-images.githubusercontent.com/361671/30746080-7e047360-9f76-11e7-8254-6c1e2e5ec9b4.png)
The Solution
Create a new console interface that better serves the user. I would:
- Have more of a curses look. So not a scrollable console.
- Segregate live-reload messages to one section / box.
- Have an area for generic error messages.
A proof of concept of this exists in the curses branch of done-serve. Here is a demonstration of what that looks like:
![untitled](https://user-images.githubusercontent.com/361671/30746577-2df50ec8-9f78-11e7-93bf-334c47fcc130.gif)
Implementation
We would like to make it possible for users to create their own UIs. We can see some exciting UIs such as:
- An interface that connects to the browser, so that messages appear there while the user works, similar to figwheel:
![68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f626861756d616e2d626c6f672d696d616765732f666967776865656c5f696d6167652e706e67](https://user-images.githubusercontent.com/361671/30746686-90ee7c26-9f78-11e7-9d61-8c4e5dcc0956.png)
- An interface that connects over a network, so that you might have your development server running on an external server and controlled remotely.
API
--ui <interface>
I propose adding a new flag to done-serve, --ui
which allows specifying an alternative UI library.
It will load the npm module done-serve-ui-<interface>
and communicate with it via an EventEmitter.
The default interface, the one that just logs everything to the console like today, could be implemented like so:
module.exports = function(events){
events.on("log", function(msg){
events.console.log(msg);
});
events.on("error", function(err){
events.console.error(err);
});
events.on("live-reload", function(msg){
events.console.error(msg);
});
events.on("server", function(url){
events.console.log("done-serve starting on " + url);
});
};
Possible UIs
Depending on what the users want, we could start building one of these UIs. Make your opinion be heard!
done-serve-ui-curses
This would be the first UI I would build, and it would be a curses interface similar to the one from the proof-of-concept. Several other ecosystems have developed similar interfaces. I think the things users care about are:
- Errors. We should make an effort to make these as clear as possible, so extracting stack trace information and displaying it better would be a major win.
- live-reload: You want to know which files are being reloaded, so if you don't see a change you expect in the browser you can look to the console to see if the module has live-reloaded yet or not.
- Statistics: Things like file sizes, API request times, and anything else that could be used to fine-tune the application.
done-serve-ui-web
This would be similar to figwheel as explained above. This would require the user inject something (maybe a can-component?) into their page, which would display the information. From there the done-serve-ui-web
package would communicate over websockets to display all of the information.