@tomlarkworthy Great seeing you here, and thanks for sharing your write up! It really goes in depth and helps a lot. Composability is what indeed I was trying to achieve, and it so happens that my intended use case and what I’m trying to troubleshoot involves your localStorageView
component! What happened is that I was trying to use @cmudig/editor
but was having trouble wiring it with localStorageView
and another button input in this notebook @jmatsushita/try-purescript
(sorry as a new user I only have a budget for 2 links
)
I suggested the following changes to @cmudig/editor
to try and make the editor reusable (which have been merged since)
// support sending and receiving updates as per https://observablehq.com/@tophtucker/custom-input-example
Object.defineProperty(container, "value", {
get() {
// console.log("editor.get called:", ed.textContent)
return ed.textContent;
},
set(v) {
// console.log("editor.set called with: ",v)
ed.textContent = v;
jar.updateCode(v);
}
});
And added a couple of use cases that were not supported before:
- Setting the value programmatically
- Supporting persistence with localStorageView
However when trying to wire both of these use cases in @jmatsushita/try-purescript
I was scratching my head and started this thread.
I tried your suggestion to create a fake source with Inputs.input()
, but It didn’t work, I think because then the binding direction with the localStorageView wasn’t right. Which led to errors
Uncaught TypeError: e.closest is not a function
at inputs.min.js:40:1444
I created a miminal reproducer here.
I think having a localStorageView means that I can use that as the “authority source” instead of needing a fake source, as per your diagram.
Is it the intended way to use localStorageView, as the “authority”?
@mootari Thank you so much.
and if desired, only the source should be declared an Observable view.
I suppose the docs weren’t crystal clear for me at least. The if desired doesn’t really carry the same meaning as “you should only have one viewof cell”, which is much clearer!
However, your solution, I think works because it avoids chaining/transitive dependencies, it doesn’t seem to be because of the viewof
usage. As you can see in the “Solution” section using viewof
everywhere seems to achieve exactly the same result.
I did implement your suggestion, using only viewof
on the source, in the section “Follow up question” just below, and it seems to behave the same. Am I missing something important here? 
Programmatically setting a form element’s value however does not automatically dispatch an event.
Oh I see, hence the “set helper” I’ve seen around which both sets the value and fires a bubbling event, pretty much exactly like the bind
code you linked. (Although I suppose it should be call the “set and dispatch helper” really).
It helps thank you! Maybe using @tomlarkworthy 's diagram and paragraph I copy pasted above would be a great addition to the docs!