Migrate inputs to Kino

[jonatanklosko]

We decided to remove inputs cells and move input functionality to Kino. This is the first step towards powering Kino with even more interactions.

With the new approach we no longer use IO for getting the input as text, instead we use Kino.Input.read, so the returned value has the expected data type. Additionally, since we create the input with code, all input settings can originate from runtime data (for instance a select box with countries from the database).

Demo

output_input.mp4

This simplifies a number of things and opens up new possibilities. Also, closes #524.

[josevalim]

Amazing! A few checks:

1. If we re-evaluate the cell that defines the input, does it keep the input value?
2. What happens if multiple inputs with the same label are defined?
3. If an input is removed, do we remove its input value from the session to avoid leakage?

issues 1 and 2 are likely related and means that inputs with the same labels should likely have their value synced. Which is fine, we only need to document it.

Design wise, I would like to propose for us to remove the output border from inputs. Otherwise, they don't feel interactive or part of the notebook. We will keep the border depending on the output type:

1. Logs, markdown, inspect values can keep the border
2. Inputs do not have the border
3. What about vegalite and datatables? This is up to you

[jonatanklosko]

1. If we re-evaluate the cell that defines the input, does it keep the input value?

Correct!

2. What happens if multiple inputs with the same label are defined?

Actually, I went with a different approach, the label is only a visual property, but it doesn't matter. Each input is uniquely identified by an id. The important part is that the id is reevaluation safe! When creating an input in Kino here we ask the group leader for a token, this token is unique but reproducible across reevaluations. We also encode the input properties as part of the id, so if they change we reset the value.

3. If an input is removed, do we remove its input value from the session to avoid leakage?

Ah good point, currently we would keep it, will improve.

Design wise, I would like to propose for us to remove the output border from inputs. Otherwise, they don't feel interactive or part of the notebook.

The question is how to handle multiple outputs, some would have border and some not? Will play around with it.

[josevalim]

One additional question: what happens if I read the input in the same cell that defines it? What happens if automatic reevaluation is defined?

The question is how to handle multiple outputs, some would have border and some not? Will play around with it.

Yeah, my thinking is that the purple left border is enough to tie them together:

[jonatanklosko]

One additional question: what happens if I read the input in the same cell that defines it?

If the input is not rendered we get an error, if it is rendered with Kino.render then it would work fine. Changing the input value would then mark the cell as stale.

What happens if automatic reevaluation is defined?

Consequently, in that case the cell would reevaluate on every input change, which I believe is expected.

[jonatanklosko]

@josevalim I removed the border for inputs and tables. For frames I made it so that it depends on the underlying output. I'm not sure if we should render images with border or not, for use cases like the game it's neat, but generally it's a regular output.

[josevalim]

@jonatanklosko let's separate multiple input into textarea and then ship it!