urlQueryFieldView (rw view interface to the URL parameters)

Show and Tell
1

Similar to Storage Location view (save view state to local storage) but now for the URL params!

So this lets you bind URL parameters to UI components, its even back-writable, so setting UI components will cause a disruptive top level navigation (don’t worry, it’s off by default).

In a job I am working on I need sensative credentials, so I pass them into a form

viewof creds = Inputs.text()

However, I hate typing them in so one upgrade is to bind that to local storage

viewof creds = Inputs.bind(Inputs.text(), localStorageView("creds"))

However, I then want a CI process testing the notebook periodically (see healthcheck). So for this use case the external test runner can additionally pass the creds in via a URL parameter

viewof creds = Inputs.bind(Inputs.bind(Inputs.text(), localStorageView("creds")), urlQueryFieldView("creds"))

EDIT: The last bind has a mistake, see urlQueryFieldView (rw view interface to the URL parameters) - #4 by tomlarkworthy, should be

viewof url = bindOneWay(
  Inputs.bind(
    Inputs.text({ label: "creds" }),
    localStorageView("creds")
  ),
  urlQueryFieldView("creds"),
  { onlyDefined: true }
)

So now creds can be set manually, or by URL params, and I have not disrupted the original notebook source at all!

1 Like
2

I would probably not list that as an example use case, since the information would make it to the server this way. :slight_smile:

3

If you want to run automated tests against a private API on Github you have to pass them a credential otherwise the bot can’t authenticate.

URL params are protected by TLS so that information stays private between sender and receiver, yet the API client notebook can stay in public.

This is quite a nice setup, as you can put public unit tests inside an public API client notebook, and run them automatically, while keeping testing creds private (well, you leak them to Observable and Webcode but this is analogous to putting credentials in any infrastructure integration, its ok, especially if you minimize the permissions attached to those creds). Users of your API notebook can even run the same unit tests but with their creds. Tests as documentation is quite nice IMHO.

4

ok when I actually got into details, the URL Input.bind would overwrite the UI control with undefined if the URL was not specified, but we don;t want to override with undefined results (e.g. we prefer a local storage fallback). So I had to use bindOneWay from view instead, that could be upgraded to do a bind only for defined values.

viewof url = bindOneWay(
  Inputs.bind(
    Inputs.text({ label: "url" }),
    localStorageView("url")
  ),
  urlQueryFieldView("url"),
  { onlyDefined: true }
)