A better console for --develop

[matthewp]

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:

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:

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:

• 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.

[chasenlehara]

Have more of a curses look. So not a scrollable console.

This sounds like we would lose access to previous messages. Can you explain this a little more?

[matthewp]

@chasenlehara

This sounds like we would lose access to previous messages. Can you explain this a little more?

It may or may not mean that. I'm not familiar enough with the curses libraries to know if, for example, the individual boxes are scrollable or not. If they are then this issue would be solved there.

Another option (which we should probably have regardless) is a --plain mode that turns off this new interface and gives you raw stdout like we have today.

[justinbmeyer]

Throwing this out there ... probably belongs in another issue ... but something to consider ...

Could we get this output to the client somehow?

Assuming the process is resilient enough to output this kind of stuff ... could we stream that to the client where it is much easier to style and present in a nice way?

[matthewp]

Yes, we should architect this in such a way as to support different presentation layers. The process that controls receiving the messages could then emit events that presenters display however they wish. Something like:

{ "type": "live-reload", "module": "main.js" }
{ "type": "error", "message": "Undefined is not a function" }

[Sinjhin]

I like it. My only concern is the same as Chasen's. It would be a pain if we didn't have access to a good bit of history. That seems like a deal-breaker to me.

[matthewp]

With blessed you can make boxes scrollable: https://github.com/chjj/blessed#options-2

[matthewp]

This has been started in the https://github.com/donejs/done-serve/tree/curses branch. I presented a demo in a past contributor's meeting