Builtin control components about histoire HOT 27 OPEN

I suggest also adding Number input, Slider, Date/Hour, Radio list, Color picker, Textarea, and JSON (with syntax highlight if possible)

Also, I suggest using a checkbox for a boolean (compared to a switch).
UX-wise, I believe switch means deciding between two states (dark/light mode for example), whereas checkbox is quite literally a boolean (checked or not checked)

from histoire.

from histoire.

Date/hour (should I use native controls or build something custom for this one?)

I think mobile native inputs are great, but desktop ones probably deserve a custom implementation because how awful they are.

from histoire.

@Akryum sounds great. I just download the repo and create a branch and push?

from histoire.

Sure!

from histoire.

I find it cleaner

from histoire.

I'm tackling the JSON code editor!

from histoire.

I'll tackle those 3:

* Slider

* Date/hour (should I use native controls or build something custom for this one?)
  
  * https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
  * https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time

* Color picker

I have noticed that the Slider component does not define a step prop, despite the slider story passing one in. I wasn't sure whether I should create a new issue about it.

from histoire.

I think we need to have some kind of ways to specify how to display those controls.
I suggest adding a controls attribute to variant, here's what it would look like:

<script lang="ts" setup>
import { BooleanCtrl, InputCtrl, SliderCtrl } from '@histoire/controls'
import MyComponent from './MyComponent.vue'
import MyCustomControlComponentfrom './MyCustomControlComponent.vue'

function initState () {
  return {
    disabled: false,
    padding: 2,
    size: 20,
    customData: {},
  }
}

const controls = {
  disabled: BooleanCtrl,
  padding: {
    type: InputCtrl,
  },
  size: {
    type: SliderCtrl,
    options: {
      min: 0,
      max: 10,
      step: 2,
    },
  },
  customData: {
    type: MyCustomControlComponent
  },
}
</script>

<template>
  <Story
    title="My thing"
    :init-state="initState"
    :controls="controls"
  >
    <template #default="{ state }">
      <MyComponent v-bind="state" />
    </template>
  </Story>
</template>

Here are some different ways to define a control:

The standard way, just specify what kind of control you want

const controls = {
  size: SliderCtrl,
}

This is an equivalent to previous example

const controls = {
  size: {
    type: SliderCtrl,
  }
}

Here you can add options to the controls (depending on what's available)

const controls = {
  size: {
    type: SliderCtrl,
    options: {
      min: 0,
      max: 10,
      step: 2,
    },
  }
}

Also, you would be able to provide your own controls (with options) like this:

const controls = {
  size: {
    type: CustomControlComponent,
    options: {
      weirdOption: 2,
    },
  },
}

Basically, anyone would be able to create their own controls for their specific purpose.
And lastly, you would also be able to use the control template to be even more free to do anything you want.

Wdyt?

from histoire.

Also, controls would be automatically inferred from the type of value if not specified.

from histoire.

I think we need to have some kind of ways to specify how to display those controls.

We already have the controls slot in the <Variant> 🤔

from histoire.

We already have the controls slot in the <Variant> 🤔

Yes, of course, but I was thinking about a way to do it "programmatically" (I mean, in JS and not directly in the template)

The advantage being that:

• the design of that part would be a bit more consistent, in compare to giving "too much" freedom to the user. For example, we could have two resizable columns with one being the name of the options, and the other being the control.
• you could automatically infer the controls of the ones which has not been specified (I believe that if we relied exclusively on templates, we could not know which options are already set up, and which ones aren't)

But it's true that we could do only the components to be placed in the controls slot for now

from histoire.

Hey there, let me know if you need hands with this :)

from histoire.

@alvarosabu sure, let me do some mockups first

from histoire.

We could also have a variant of HstRadio with checkboxes, called HstMultiCheckbox

from histoire.

I will take HstSelect first

•   Select

from histoire.

So I'm basically done with the Select component. I will need access to push the branch and create the PR @Akryum when you have a chance.

from histoire.

Done

from histoire.

Nice, it's ok if I take next?

• Radio list
• Checkbox list

Cheers

from histoire.

@Akryum I have one question regarding the radio list, I see you implemented the HstCheckbox width SVGs and no input element (faked with a div). Is there a specific reason to not use native input tags?.

Is the radio component expected to be implemented in the same way or I can use input + label and just hide the input visibility?

Thanks

from histoire.

I'll tackle those 3:

• Slider
• Date/hour (should I use native controls or build something custom for this one?)
  • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
  • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time
• Color picker

from histoire.

If I may suggest I think the next one should be JSON code editor since for now the auto-props don't show the initial data and we also aren't able to specify the type of input, then we need to use the controls template. That way we could use the new feature that allows us to hide the auto-props avoiding displaying the same stuff twice.
Thanks

from histoire.

@MikhaD The step property is indeed not defined in the component. So it's available in the $attrs, which is directly passed to the input HTML element like this:

<input
  v-bind="{ ...$attrs, class: null, style: null, min, max }"
>

(The class: null, style: null is to remove any class of style set, as it's already added to the HstSlider root element)

Hope it answers your concerns 🙂

from histoire.

I appreciate the response.

I use Histoire for Svelte, not Vue, so unfortunately the solution does not apply.

I have a work around for now, my question is is there a reason that step is not defined or is an oversight that should be placed in a bug report.

from histoire.

The absence of the step prop was intended at the time of building the component, since it was not needed.

But if it can't be used in svelte, that's indeed a bug.

Out of curiosity, what workaround have you found?

from histoire.

I made my own identical looking svelte component with a range prop that I use instead. It is not quite as good, because it doesn't have the tooltip.

Why do you say step was not needed?

from histoire.

Why do you say step was not needed?

IIRC, I built that feature when Histoire didn't support Svelte yet. So the step prop worked anyway. I'll have to take a closer look to fix it for Svelte 🙂

from histoire.