Tom Larkworthy

Was this a conscious pun by the way? :D

https://en.wikipedia.org/wiki/Dynamic_range

Job van der Zwan

well I was aware of the pun when I wrote it but was not aiming for a pun. So yes and no.

Really like how these simple bindings already enable complex behaviour

Regarding the "bug": every aspect of inputs is hidden behind an abstraction, it's not just DOM nodes and their properties, but also callbacks and values in closures. Imo there's no way for nanomorph to handle this without a possibly significant rewrite of some inputs (e.g. in select() each option element would need to reference its original configuration and data separately, essentially becoming a component).

Fabian Iwand

yeah this can't really be fixed. Kind of a shame but for simple use cases its ok.

Why the need for a lodash path? Wouldn't an acccessor be more flexible and only slightly less convenient? E.g.

  dynamicRange = juice(Inputs.range, {
    label: d => d[1].label,
    min: d => d[0][0], 
    max: d => d[0][1], 
  })

This would allow for a (subjectively) nicer API as well, e.g.:

  dynamicRange = juice(Inputs.range, {
    label: (d, o) => o.label,
    min: d => d[0], 
    max: d => d[1], 
  })

the path is also used to read from the initial args to initialize the values

I'm not following. How does that interfere with accessors?

u need one of reading and one for writing, so it's two per subview, right? you have only done the read API in Ur example, u need to write them too

I use _.update and _.get and reuse a path between them, maybe that's a more exact way of saying it