New Sliders!

[SyxP]

This reimplements Sliders solving two issues:

1. It starts on the proposed rewrite in HypertextLiteral.jl as stated in [WIP] refactoring PlutoUI with Mustache #62 and Rewrite to use Hyperscript.jl #59 .
2. This fixes a issue that with multiple of the same Slider with show_value = true, moving a Slider would only change the display of the various input ranges, but not the display of the value. This syncs all the values, solving @bind doesn't update showed value for multiple instances in different cells #96 .

Unfortunately, there is a slight caveat to consider. Traditionally, the Slider is seen as the "simplest" example of PlutoUI and a good way to introduce the ecosystem. However, this rewrite makes use of fairly nasty tricks to ensure (2) above.

[fonsp]

Great! Some short comments based on reading the code:

• Can I still place it inline? md"Hello $(@bind x Slider(1:10)) world"? If not try replacing <div> with <span>
• We should use the struct because it defines Base.get, see the Interactivity sample notebook inside Pluto to learn what this means

[SyxP]

I have undid the changes so that it is now Slider <: DataType and re-added the get function. Moreover, you're right, I didn't notice that <div> will consume the whole-line and changed it to <span>. (I only started learning js because of Pluto 😄 )

Let me elaborate a bit more on the overwriting the div valuesetter. Observe the sample notebook on Javascript, if you create two cells saying

1. t = @bind num_clicks ClickCounter()
2. t

when you observe num_clicks, each click counter will carry its own internal state. Thus, simply adding

Object.defineProperty(div, "value",
  {configurable: false, enumerable: false,
  get: () => {return count},
  set: (newVal) => {
    count = newVal
  }})

would cause the individual click counters to update the local variable when the outer div's value property gets set.

[fonsp]

Instead of generating JS like this, can you add line 34:

let show_value = $(show_value)

and then use normal JS in this line?

[SyxP]

The reason for I feel that doing so is superior is two-fold:

1. This minimizes the javascript on the page being rendered. When one attempts to study the Pluto cells, it is easier to understand if we provide less code in the first place, rather than having a bunch of objects in the page and hiding their visibility on the browser. Here, we minimized the code sent between the server and the client.
2. The pedagogical advantage of showing an example where we interpolate javascript code using Julia is very useful in my opinion.

[fonsp]

I don't want to linger on this point but 1. is not a necessary optimization, and I see 2. exactly opposite: I don't want to teach this code style to people, so we shouldn't use it ourselves.

[fonsp]

Implemented in #148 , thanks for thinking together!