blueprint: Form Controls JS API does not document disable parameter

Bug report

Package version(s): 1.4.0
Browser and OS versions: All

Actual behavior

Disabling Form controls (e.g. Checkbox) is possible using the CSS API. It’s a bit cumbersome though. A className modifier has to be applied to the label and a a parameter modifier has to be applied to the input tag itself. I wanted to use the JS Component (e.g. <Checkbox>) hoping that it would have a simple disabled or isDisabled parameter, but it does not seem to exist. Most input form controls seem to allow disabling them through the CSS API, but not through the JS API

Apologies if I’m missing something in the documentation.

Expected behavior

I would expect a simple disabled parameter to exist on most Form Control components.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 16 (10 by maintainers)

Commits related to this issue

make the `$button-intents` map override-able (per https://github.com/palantir/blueprint/issues/396#issuecomment-270191014) — committed to palantir/blueprint by deleted user 7 years ago
more !default Sass variables (#399) * more `!default` variables (missed a few last time) * make the `$button-intents` map override-able (per https://github.com/palantir/blueprint/issues/396#issue... — committed to palantir/blueprint by giladgray 7 years ago

Most upvoted comments

Yep - absolutely. New issue is here: #402. Thanks again for all the support!

isTravis on Jan 3, 2017

Ya, I hear ya. And you of course have a much better overview of the project and how it’s structured, so I defer to your insight.

I agree it’s odd to change just the two blues, in my specific case I want to merge the blues and grays, so ideally I’d do something like this:

$blue1: $gray1;
$blue2: $gray2;
$blue3: $gray3;
$blue4: $gray4;
$blue5: $gray5;
$blue6: $gray6;

Even though this is a bit heretical, because now I have something called blue that isn’t blue, it

Prevents me from having to search though all the instances of $blue and overwrite them. (I agree, there’s more control by doing so, but in this case, I don’t want more control).
Future-proofs my code so that if a new component or SCSS class is added, I don’t have to go searching through the library to compare what has changed.

Adding the !defaults also doesn’t prohibit anyone from treating the colors as Immutable or having the fine-grain control of overwriting other variables. It could simply be stated that the best practice is to not mutate the colors, but if for some reason I want to rotate the reds, I could.

Anyways - I’m sure you’ve given this lots of thought already, so this is just my two cents. I’m also fairly off topic from the original Issue I had posted, so I’m happy to move this discussion to #377 or just finish it there.

Thanks again, I really appreciate all your work and effort on this!

isTravis on Jan 3, 2017