# The \`.value\` is a lie.š (on viewof'ed inputs at least)
**URL:** https://talk.observablehq.com/t/the-value-is-a-lie-on-viewofed-inputs-at-least/4343
**Category:** Help
**Created:** [December 16, 2020, 12:42pm UTC](https://talk.observablehq.com/t/the-value-is-a-lie-on-viewofed-inputs-at-least/4343 "2020-12-16T12:42:26Z")
**Posts on this page:** 5
**Page:** 1
Hey folks,
According to [https://observablehq.com/@observablehq/introduction-to-views](https://observablehq.com/@observablehq/introduction-to-views)
these two snippets should be equivalent.
```auto
box // true
```
```auto
(box, viewof box.value) // "on"
```
given that
```auto
viewof box = html``
```
However the latter returns the `value` attribute of the dom node, which is āonā by default.
So what kind of magic is actually happening under the hood?
Is Observable just treating inputs differently and using `value` for everything else?
Resetting the value and firing an `input` event doesnāt actually change the value propagated to the cells depending on it, probably because itās fired on the input cell, and not on the stdlib `Generators.input` object.
Is it possible to access that object directly? Should `Generators.input` register an `input` event listener on itās wrapped value? Thoughts?
---
Think of `viewof` as a macro that produces an additional Runtime `Variable` (internal represenation of a cell) for your viewof cell, so that you end up with two Variables:
- `viewof box`, the cell that you originally defined,
- `box`, which is a generator cell that listens to changes in `viewof box` via Generators.input and yields the new value.
Generators.input has some āmagicā for inputs. Depending on the input type, it will:
- listen to different events (e.g. āclickā for checkboxes),
- cast the value (e.g. via `.valueAsNumber()` for number and range inputs).
You can find the implementation details here:
>
In general I find that looking at a notebookās generated source can give some insight into the underlying logic, e.g.:
[https://api.observablehq.com/@observablehq/introduction-to-views.js?v=3](https://api.observablehq.com/@observablehq/introduction-to-views.js?v=3)
---
Hey @mootari,
Yeah, so the `.value` is just the default case.
However then Iād actually argue that `Generators.input` has a bug, in that it should also listen for āinputā events.
Yes one could emit a āclickedā event for checkboxes e.t.c. but that feels like a weird API violation, no? I mean ideally instead of using āvalueā observable would probably use a `Symbol('value')`
to prevent data transparency issues, but I guess thatās too late now š.
Btw, while I got you on the figurative phone, thereās a small bug in [Mutable Forms / Fabian Iwand / Observable](https://observablehq.com/@mootari/mutable-forms) where it breaks for `checkbox` with just a single value. I havenāt tracked down the bug far enough, but it looks like browsers automatically wrap multiple checkboxes in a `RadioNodeList` but leave single checkboxes as is.
Yay auto unwrapping -.- .
---
> [@somethingelseentire](#):
>
> However then Iād actually argue that `Generators.input` has a bug, in that it should also listen for āinputā events.
That would cause the generator to yield multiple times for a single update. If you want to investigate and visualize the events, have a look at [Monitoring Events / Fabian Iwand | Observable](https://observablehq.com/@mootari/monitoring-events).
> [@somethingelseentire](#):
>
> However then Iād actually argue that `Generators.input` has a bug, in that it should also listen for āinputā events
As far as I recall there are some problems with input events on checkbox elements, specifically that the checked state will still have the old state when the event is raised. However, you can work around the issue by wrapping your element in a span or div and either have the input event bubble, or trigger it directly on the wrapper.
> [@somethingelseentire](#):
>
> thereās a small bug in [Mutable Forms / Fabian Iwand | Observable](https://observablehq.com/@mootari/mutable-forms) where it breaks for `checkbox` with just a single value
Thanks, [fixed](https://observablehq.com/compare/6b56a2a00cbb4676@560...6b56a2a00cbb4676@605)!
---
Ah yeah youāre right.
Normally I really appreciate observables ānothing in-betweenā approach, but I think in this case it would have been fine to add a bunch of shim methods to input elements the moment they are passed to `Observers.input`, which abstract away the different behaviours and package them into one neat āinputā event and `Symbol(value)` attribute.
Anyways, thanks for the help, and the fix! š