Making the `select` with strings that contain double quotes

Community Help
1

First of all, I’m very grateful for @jashkenas’ wonderful inputs notebook. But I was a bit surprised by this:

image
image.png828×129 9.61 KB

I tried escaping with \ but that didn’t work.

Eventually, I figured out the following workaround: put the names in a separate array (selectionNames in my case), put the code snipped below in the select, then elsewhere refer to selectionNames[imageSelect] to get the actual string.

viewof imageSelect = select({
  title: 'Select Image from default set', 
  options: selectionNames.map((label, value) => ({label, value})),
  value: 0
})

So I already got things working, but still: I wonder if the following could be made to work out of the box somehow.

2

Yea, that’s a bug in the Inputs notebook, which should escape the values when generating the HTML. Currently it’s using an html tagged template literal, but that doesn’t do any escaping.

3

It should be fixed now. Thanks for the bug report, @Job!

1 Like
4

The fix seems to break some of my notebooks! Some started to hang.

It took me a couple of hours to find out. I had to change:

 sel.value = habitats.find(r => r.name === sel.input.value)

to:

 sel.value = habitats[sel.input.value];

E.g. I had to change habitat in Magic Balls Factory; had to fix cell curve in CFD as well.

viewof habitat = {
  const sel = select(habitats.map(r => r.name));
  sel.oninput = () => {
    // Kudos to Jeremy Ashkenas for this nifty trick.
    // sel.value = habitats.find(r => r.name === sel.input.value); <= hangs since Oct 18!!!
    sel.value = habitats[sel.input.value];
  };
  sel.oninput();
  return sel;
}
1 Like
5

If you want to protect your notebook against the imports changing, you can pin the version of the import. For example, this is the latest version:

import {select} from "@jashkenas/inputs@1581"

This is the version prior to Jeremy’s fix:

import {select} from "@jashkenas/inputs@1571"

Currently, the easiest way to determine the version of the notebook is to use the JavaScript API, and look for the “Version” comment at the top:

https://api.observablehq.com/@jashkenas/inputs.js

Incidentally, this API endpoint also supports versioning:

https://api.observablehq.com/@jashkenas/inputs@1571.js
https://api.observablehq.com/@jashkenas/inputs@1581.js

In the near future, we’re planning to let you browse published versions, and we’d also like import statements to pin the current version automatically to prevent notebooks from breaking when their imported notebooks change.

1 Like
6

That’s great. Thanks.

Even greater would be to get notified when a imported notebook changes (release notes, #updates number in a red circle?).

Yet even greater would be if changes are upwards compatible so they don’t break your notebook. Incompatible changes may include help to best refactor or migrate to the latest version.

Maybe stick with the working revision by default and make upgrading optional?

Also, it seems like proper string processing should have no breaking side effects in code logic? I did not do a deepmdive into the changes, though.

7

That’s the goal with pinning version numbers by default. The plan is if you delete the pinned version number, it’ll automatically re-pin to the current latest version.

1 Like