-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate inputs to Kino #714
Conversation
f0206ba
to
0417640
Compare
Amazing! A few checks:
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:
|
Correct!
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.
Ah good point, currently we would keep it, will improve.
The question is how to handle multiple outputs, some would have border and some not? Will play around with it. |
Co-authored-by: José Valim <jose.valim@dashbit.co>
One additional question: what happens if I read the input in the same cell that defines it? What happens if automatic reevaluation is defined?
Yeah, my thinking is that the purple left border is enough to tie them together: |
If the input is not rendered we get an error, if it is rendered with
Consequently, in that case the cell would reevaluate on every input change, which I believe is expected. |
7d1da8b
to
55a6c4e
Compare
@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. |
@jonatanklosko let's separate multiple input into textarea and then ship it! |
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 useKino.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.