Does this library support collapsing and grouping?

[marcofugaro]

Sometimes the variables can be a lot, so grouping and collapsing of the inputs can be really useful.

Here is an example oh what I'm talking about:

http://www.curious-creature.com/pbr_sandbox/

dat.gui of course supports it and it's very useful, any plan for this library to support it?

[rreusser]

No, it doesn't. I wanted to add that, but in my opinion, I would love to rewrite this module with, for example, preact, so that you could make the UI nice and declarative and change it after instantiation. And so that you can compare previous and next values whenever the state changes. Long story short, it could, but there are a few hitches that prevented me from investing more time in it, even though I do love this module and use it all the time.

[dy]

@rreusser do you have an idea for the API? I can imagine something like

import {Panel, Number, Color, Group} from 'control-panel'

...
<Panel theme={'black'}>
  <Group title="Coordinate" collapsed>
    <Number id="x" min={-100} max={100} />
    <Number id="y" min={-100} max={100} />
  </Group>

  <Color value="#abcdef"/>
</Panel>

[rreusser]

Ah, interesting… What about keeping a somewhat similar API and using (p)react internally (basically exactly as you described; just internal)? Mainly because exposing react directly either makes it pretty verbose via the hyperscript h(...) API and lots of requires, or it introduces a dependency on ES6 and JSX in order to roll it up reasonably.

Also, it requires the user to install/manage/instantiate react, which is real easy; just actually requires putting that ball in their court. Though it would be nice to leave the option open by virtue of design.

What about:

// Should this get mutated directly? It's actually rather convenient to just
// access state properties directly. Otherwise I *always* have to run
// Object.assign(state, newState) in the event handler with a bunch
// of checks for particular changes
var myState = {
  x: 5,
  y: 7
};

var panel = controlPanel(myState, [
  {
    type:  'group',
    title: 'Coordainate',
    collapsed: true,
    fields: [
      // If we pass a state object, you don't need `initial` anymore, which is
      // pattern you *always* have to use that gets really tiresome.
      {type: 'Number', id: "x", label: "x", min: -100, max: 100},
      {type: 'Number', id: "y", label: "y", min: -100, max: 100},
    ]
  },
  {type: 'color', value: '#abcdef'}
], {
  theme: 'black'
}).on('input', function (newState, previousState) {
  // live changes as you, say, drag a slider. Note though that maybe you
  // don't even need this callback if we mutate the input object for
  // convenience. This callback would instead be for performing actions
  // on *particular* changes
}).on('inputend', function (newState, previousState) {
  // at the end of an input event since some things need live updates
  // while other things are too expensive for that?
})

// Change the fields. For example, you could remove a field. Each field
// should probably have a visible attribute so you can simply hide it and
// set the fields
panel.setFields({
  // totally new fields?
});

// An issue I've had is feeding changes back in. An example is:
// https://rreusser.github.io/demos/double-pendulum/
// You don't want to know what I had to do to get the preset menu to work…
panel.setState({
  x: ...,
  y: ...,
});

[rreusser]

Oh, and one other thing is that the values need to overlay the sliders! And the sliders need to work on mobile without trying desperately to hit the 5x5px region that actually affects the slider! Pushing values into a small box makes for lots of problems in which decimal places get cut off!

Oh, and what about:

EDIT: actually, what about either rolling it up in an API that entirely hides react or allowing you to use the components directly, rather than this indecisive stuff:

import {Number} from 'control-panel'

controlPanel(myState, [
  <Number min=10 max=20 id="x"/>,
  {type: 'number', id: 'y', min: 10, max: 20}
])

I guess there's no reason it couldn't just allow react component instances too……… because probably all the "type" fields do is just instantiate a component anyway… Probably some issues, but it might allow for easy customization

[rreusser]

One last thought is that I often just use it as a single command, which makes for very low mental overhead, e.g.:

require('control-panel')([
  {type: 'number', label: '...'},
]).on('input', ...);

[rreusser]

Update: I've finally cleaned up my honest stab at this.

You can find a short writeup here: https://rreusser.github.io/control-panel-2/

The source lives here: https://github.com/rreusser/control-panel-2

And, naturally: https://observablehq.com/@rreusser/control-panel-2-prototype-test.