# input library (@jashkenas/inputs) not mutable; but normal views are mutable

**URL:** <https://talk.observablehq.com/t/input-library-jashkenas-inputs-not-mutable-but-normal-views-are-mutable/1382>\
**Category:** Help\
**Created:** [November 2, 2018, 1:36am UTC](https://talk.observablehq.com/t/input-library-jashkenas-inputs-not-mutable-but-normal-views-are-mutable/1382 "2018-11-02T01:36:51Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![theredpea](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/theredpea/32/1076_2.png) [@theredpea](https://talk.observablehq.com/u/theredpea)\
**Post date:** [November 2, 2018, 1:36am UTC](https://talk.observablehq.com/t/input-library-jashkenas-inputs-not-mutable-but-normal-views-are-mutable/1382/1 "2018-11-02T01:36:51Z")

</div>

Right now in my Observable learning curve my Observable cells are simple\*; each cell represents one value assigned directly; like:

```
viewof library_input = text({value: 'library_input' })

```

Then I want to change the value of library\_input. No problem, [views are mutable values](https://beta.observablehq.com/@mbostock/views-are-mutable-values)

```
viewof library_input.value = 'new library_input val 

```

But that doesn’t change/mutate the value of the `text` input! Doesn’t change the value of an `input` (or a `text` or a `select`).

I _can_ assign to a “plain” view; this works the way I’d expect

```
viewof html_input
viewof html_input.value = 'new html_input val'

```

Is this expected, am I doing anything wrong, is there a better approach?

(I tried to give example here: [library input vs plain view / Nate | Observable](https://beta.observablehq.com/@theredpea/untitled) \*\* )

* * *

\*Maybe more smaller cells is a better (more “Observable”) approach than…

> [@Multiple mutables and an interactive view](https://talk.observablehq.com/t/multiple-mutables-and-an-interactive-view/568/1):
>
> putting everything in a single big cell

\*\*Unrelated, I like human-friendly URLs , but when I publish a new notebook _before adding a title_, I create URLs like this (note `untitled`): [library input vs plain view / Nate | Observable](https://beta.observablehq.com/@theredpea/untitled) At the moment I can’t fix this, even if I’ve added a title (markdown in first cell?), and re-published, etc…

---

<div class="post-metadata">

**Author:** ![bgchen](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/bgchen/32/784_2.png) [@bgchen](https://talk.observablehq.com/u/bgchen)\
**Post date:** [November 2, 2018, 2:41am UTC](https://talk.observablehq.com/t/input-library-jashkenas-inputs-not-mutable-but-normal-views-are-mutable/1382/2 "2018-11-02T02:41:17Z")

</div>

I think you get what you want if you change:

```auto
viewof library_input.value = change_library_input ? 'changed library_input val' : 'original library_input val';

```

to

```auto
viewof library_input.input.value = change_library_input ? 'changed library_input val' : 'original library_input val';

```

(The `text()` gadget that you imported from @jashkenas’s notebook actually creates a `<form>` element containing a child element `<input name=input>`. We use the `.input` to access that input element by name.)

---

<div class="post-metadata">

**Author:** ![theredpea](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/theredpea/32/1076_2.png) [@theredpea](https://talk.observablehq.com/u/theredpea)\
**Post date:** [November 4, 2018, 5:31pm UTC](https://talk.observablehq.com/t/input-library-jashkenas-inputs-not-mutable-but-normal-views-are-mutable/1382/3 "2018-11-04T17:31:46Z")

</div>

Thanks @bgchen !  
As you say the `@jashkenas/input` library wraps each control in a `<form>` element; aka “wrapper element”.

A few interesting notes:  
These produce the same thing. I thought the parentheses may cause `viewof` to apply to different values. But these all produce the same result; the `HTMLInputElement` of the `<input type="text">` named `input`

```
viewof library_input.input
(viewof library_input).input
(viewof library_input.input)

```

But now I’m thinking `viewof` applies to the values to its right, even before the dot operator (higher precedence). Maybe that’s why `viewof` doesn’t like parentheses to its right. Maybe `viewof` has highest precedence; must evaluate first. Which might explain why the above parentheses change doesn’t make a difference, and these parentheses cause error:

```
viewof (library_input.input)
SyntaxError: Unexpected token

```

Even if we access the input(s) inside each form, it may not work. I think this is a general challenge with HTML elements. For example in plain HTML/DOM APIs, changing a `<input type="text">` is as simple as setting the `value` attribute, and getting the attribute again:

```
document.querySelector('[name=library_input]').value= 'new library input'
document.querySelector('[name=library_input]').value

```

However, other controls like `<select multiple>` or `<input type="checkbox">` are not so easy to get/set.  
For example, setting `<input type="checkbox">` requires [adding the `checked` attribute](https://stackoverflow.com/a/12700656/1175496) and/or [setting the `checked` property](https://stackoverflow.com/questions/8206565/check-uncheck-checkbox-with-javascript).  
Likewise, getting the value of a `<select multiple>` is not as easy as reading a single `value` attribute. Instead [each child `option` element must be checked](https://stackoverflow.com/a/31544256/1175496)

While `@jashkenas/input` supports `getValue` to convert HTML state to a value but there is no concept of `setValue`. (Here’s how `@jashkenas/inputs` getValue of a `<select multiple>`)

```
getValue: input => {
  const selected = Array.prototype.filter
    .call(input.options, i => i.selected)
    .map(i => options[+i.value].value);
  return multiple ? selected : selected[0];
},

```

The `@jashkenas/inputs` strategy of wrapping input(s) in a container like a `<form>` is also used in [linked inputs](https://beta.observablehq.com/@mbostock/linked-inputs) and [multi-value inputs](https://beta.observablehq.com/@mbostock/multi-value-inputs)\*\*\*. I cannot _set_ the value in either of those notebook either; this doesn’t work in the multi-value input notebook:

```
viewof rgb.value = [120, 100, 90]

```

So the concept of `setValue` is a common challenge. One solution is to use the [“more general approach … a _minimal_ view”](https://beta.observablehq.com/@mbostock/synchronized-views). The `set` is supported as part of the `EventTarget interface` provided in the `View` class: `import {View} from "@mbostock/synchronized-views"`

```
set value(value) {
  this._value = value;
  this.dispatchEvent({type: "input", value});
}

```

But then you must `bind` your view to your input(s):

- addEventListener to react : when the View (EventTarget) changes -\> update your input
- listen to your input to react: when user changes the input -\> update the View

Note about the “wrapper element” as I call it:

- [`@jashkenas/inputs`](https://beta.observablehq.com/@jashkenas/inputs) uses an **explicit** `<form>` element
- [multi-value inputs](https://beta.observablehq.com/@mbostock/multi-value-inputs) uses an **explicit** `<div>` element
- [linked-inputs uses](https://beta.observablehq.com/@mbostock/linked-inputs) an **implied** `<div>` element

All three cases assign the property `value` to the wrapper element so the `viewof` operator can get what it needs.

---

<div class="post-metadata">

**Author:** ![mootari](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/mootari/32/581_2.png) [@mootari](https://talk.observablehq.com/u/mootari)\
**Post date:** [November 9, 2018, 6:29pm UTC](https://talk.observablehq.com/t/input-library-jashkenas-inputs-not-mutable-but-normal-views-are-mutable/1382/4 "2018-11-09T18:29:39Z")

</div>

Regarding `viewof`: Place a `debugger;` statement somewhere near `viewof` and you’ll see that `viewof varname` gets replaced with `$0` (or `$1` etc.).

As for mutating form widgets, you might find this notebook helpful: [https://beta.observablehq.com/@mootari/mutable-forms](https://beta.observablehq.com/@mootari/mutable-forms)