[RFC]: add object inspection on the fly in REPL

[Snehil-Shah]

Description

This RFC proposes improving the REPL by adding information about functions and objects (in grayed out text) as you type in the REPL for a more insightful editing experience.

Inspired by the node.js REPL:

Related Issues

Related Issues #1775, stdlib-js/google-summer-of-code#1

Questions

No.

Other

No.

Checklist

• I have read and understood the Code of Conduct.
• Searched for existing issues and pull requests.
• The issue name begins with RFC:.

[Snehil-Shah]

If this feature is entertained, I would like to work on it!

[tudor-pagu]

Hi, I've just noticed that this RFC and RFC #1775 (proposed by me) are quite complementary, as they both involve the gray preview inspired by nodeJS. I think the object inspection should also be shown together with the preview, whenever there is only one possible completion.

Let me know if you could use any help! I can show you how my implementation works (I've mostly completed the preview functionality).

[Snehil-Shah]

Hi, I've just noticed that this RFC and RFC #1775 (proposed by me) are quite complementary, as they both involve the gray preview inspired by nodeJS. I think the object inspection should also be shown together with the preview, whenever there is only one possible completion.

Let me know if you could use any help! I can show you how my implementation works (I've mostly completed the preview functionality).

Thanks! I'll let you know if I need help..

[Snehil-Shah]

Hey @tudor-pagu , implementing object inspection would take the same approach you took with PR #1832, so it would be better if you implement this in the same PR. Would you like taking over this issue? Keep in mind it's not yet accepted by the maintainers so ask once before implementing.

[tudor-pagu]

Hi @Snehil-Shah, I would be happy to take over this issue. I will ask about it on my PR.

[kgryte]

I suggest we get #1832 over the finish line first and then revisit this issue, as it could be implemented in a follow-up PR. I'd like to avoid overloading that particular PR, given that it is already shaping up to be fairly involved.

[kgryte]

One question I have about this proposal is how would it handle more complex evaluations.

Based on my knowledge, you essentially need to perform constant evaluation of the typed input before a user presses ENTER. I can imagine a scenario in which a particularly computationally expensive task ends up running repeatedly, causing the REPL to slow considerably due to tied up resources.

Additionally, what about large outputs? E.g., suppose I am transforming an array of 1000 elements. Evaluating and showing the result could result in a large blob of text being written to the preview.

How would this work with, say, async calls in which an expression is fetching resources from a remote resource? Doing this before pressing ENTER could mean unnecessary requests.

Also for asynchronous expressions (note we support both async/await and async callbacks), there might be a lag in returned results resulting in the displayed output being different from what might be expected based on the current text a user has entered. I can imagine this lag leading to user confusion.

[Snehil-Shah]

One question I have about this proposal is how would it handle more complex evaluations.

Based on my knowledge, you essentially need to perform constant evaluation of the typed input before a user presses ENTER. I can imagine a scenario in which a particularly computationally expensive task ends up running repeatedly, causing the REPL to slow considerably due to tied up resources.

Additionally, what about large outputs? E.g., suppose I am transforming an array of 1000 elements. Evaluating and showing the result could result in a large blob of text being written to the preview.

How would this work with, say, async calls in which an expression is fetching resources from a remote resource? Doing this before pressing ENTER could mean unnecessary requests.

Also for asynchronous expressions (note we support both async/await and async callbacks), there might be a lag in returned results resulting in the displayed output being different from what might be expected based on the current text a user has entered. I can imagine this lag leading to user confusion.

We don't evaluate expressions in the preview, we just provide object inspection using something like util.inspect.
Object inspection just shows us the properties of the object, it doesn't evaluate the expressions.

In the image attached with OP, console is an object with various functions like log, warn and that is conveniently displayed in the preview.
when I type a function say foo(), the preview will show [Function: foo], when we have an async function the preview will show [AsyncFunction: foo], when we have an unresolved promise, it shows Promise { <pending> }, without evaluating any of the functions or asynchronous operations.

And regarding huge blobs of text, node.js limits it to one line in the terminal, and ends with three dots instead of overflowing it to the rest of the terminal

[kgryte]

@Snehil-Shah Ah, right. Sorry, I was getting this confused with eager evaluation.