Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: different states for the buttons #221

Open
WilliamStam opened this issue Sep 7, 2022 · 0 comments
Open

Suggestion: different states for the buttons #221

WilliamStam opened this issue Sep 7, 2022 · 0 comments

Comments

@WilliamStam
Copy link

WilliamStam commented Sep 7, 2022

Couldnt submit a PR :(

Currently using bootstrap (but the same for tailwinds etc) you have a base class ie .btn. For inactive buttons if you want to apply a class .btn-light and for active (selected) buttons want to add a .btn-primary you have to resort to "recreate" the button definitions with a :not(.selected) type setup.

This seems trivial for the most part, but being able to differentiate between the various states like this definitely gives more power to the developer using the awesome library.

https://github.com/WilliamStam/pell will let you define the button classes as
master...WilliamStam:pell:master Showing with 22 additions and 4 deletions. (additions were mostly the backwards compatability part)

const classes = {
    actionbar: "...",
    button: {
        default: "pell-button",
        inactive: "pell-button-inactive",
        active: "pell-button-active"
    },
    content: "...",
}

I've added some backwards compatible code in that

const classes = {
    actionbar: "...",
    button: "pell-button",
    selected: "pell-button-selected"
    content: "...",
}

will translate to the button object above


Code stuff - the changes

This looks a bit messy, but hopefully it can be removed in future breaking change versions. Need to set the classes.button to an object just so that we dont have to do checks every time we want to use clases.button.active (any of the states) in the code later on.

// Backwards compatibility
  if (typeof settings.classes.button !== 'object'){
    settings.classes.button = {
      default: settings.classes.button ?? defaultClasses.button.default,
      active: settings.classes.selected ?? defaultClasses.button.active,
      inactive: defaultClasses.button.inactive,
    }
  }
  // end of backwards compat

When setting up the buttons they are in a default state as well as inactive

actions.forEach(action => {
    const button = createElement('button')
    button.className = classes.button.default + " " + classes.button.inactive
...

if the button has a state option and the state is "active" then remove the inactive class and add the active class, and visa versa.
This way you dont end up with a situation where some of the inactive and some of the active styles pull through

if (action.state) {
      const handler = () => {
        button.classList[action.state() ? 'add' : 'remove'](classes.button.active)
        button.classList[!action.state() ? 'add' : 'remove'](classes.button.inactive)
      }
      ...

Not sure why the handler isnt called immediately to define the state of the button. i suspect this is superfluous tho since it depends on where the cursor is, this isnt needed for the above suggestion to work and can be removed.

      ...
      addEventListener(button, 'click', handler)
      handler()
    }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant