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

Addon-controls: Conditional arg disabling #13890

Closed
wants to merge 12 commits into from
Closed

Conversation

shilman
Copy link
Member

@shilman shilman commented Feb 12, 2021

Issue: #11984

What I did

Simplified disabling of individual args in ArgsTable, also disable controls conditionally on other controls:

argTypes: {
  foo: { disable: true }, // disable
  bar: { table: { disable: true } }, // disable and log deprecation warning
  baz: { disable: 'foo' } // disable when foo is truthy
  moo: { disable: '!foo' } // disable when foo is falsey
}

Some examples:

conditional-controls

How to test

See updated stories & unit tests

@shilman shilman added addon: controls args maintenance User-facing maintenance tasks feature request and removed maintenance User-facing maintenance tasks labels Feb 12, 2021
@tmeasday
Copy link
Member

Does this have meaning outside of args table?

@shilman
Copy link
Member Author

shilman commented Feb 15, 2021

Not currently, but it could. Disabling args entirely could disable them from being serialized, or disable them from URL sync. WDYT @tmeasday @ghengeveld?

Rationale for this PR: table.disable is too verbose for something that is pretty common. I also merged another PR that makes removing args from the table more ergonomic #13898

@ghengeveld
Copy link
Member

LGTM

@ghengeveld ghengeveld assigned shilman and unassigned ghengeveld Feb 26, 2021
@ghengeveld ghengeveld mentioned this pull request Mar 2, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Apr 22, 2021

Fails
🚫 PR is marked with "do not merge" label.

Generated by 🚫 dangerJS against 72e4364

@shilman shilman changed the title Addon-controls: Improve arg disabling Addon-controls: Conditional arg disabling Apr 22, 2021
@shilman
Copy link
Member Author

shilman commented Apr 22, 2021

Feedback from @ndelangen - let's make disable: true disable in the args data structure, not just in the table UI. Then this PR is self-consistent.

@nx-cloud
Copy link

nx-cloud bot commented Apr 30, 2021

Nx Cloud Report

CI ran the following commands for commit 72e4364. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

Status Command
#000000 nx run-many --target=prepare --all --parallel --max-parallel=15

Sent with 💌 from NxCloud.

@shilman
Copy link
Member Author

shilman commented May 10, 2021

  • Question: transitive behavior? circular behavior? => Throw an error/warning if possible?
  • Enable/disable vs include/exclude vs invent our own expression language
  • Does making it a function work?

@jorisw
Copy link
Contributor

jorisw commented Jul 26, 2021

Why was this PR closed?

This comment best describes why this is needed.

@shilman
Copy link
Member Author

shilman commented Jul 26, 2021

@jorisw this PR was a POC. we haven't decided whether to add this feature to controls and plan to revisit the decision based on the community response.

notlee added a commit to Financial-Times/origami that referenced this pull request Jan 10, 2022
Adds a `destroy` method to o-banner. This is used in the o-banner
Story to clean up the close button when re-rendered, which o-banner
dynamically creates on `init`. This is required to support the
`suppressCloseButton` Story control.

It appears banner headings (headingLong/headingShort) should only
be used with the small/compact layout variants. Not with the default
banner style which is full bleed. However it is possible to use
Story controls to create that view.

`@storybook/addon-knobs` (deprecated) allowed dynamic knobs,
so we could hide the heading controls if the default layout
was selected. That's not possible with `@storybook/addon-controls`:
storybookjs/storybook#11984

I think that's probably a good thing. Support for
dynamic controls was worked on but not merge. It's
a poor experience when controls shift around.
storybookjs/storybook#13890

For now this commit hides the layout control on layout
demos, and hides the heading controls from the default
layout demo, to avoid showing the discouraged
heading + layout combination. However it is still
possible to select the base layout with heading on the
theme specific demos, so that the small/compact layout
can also be selected which is allowed.

This could be resolved by exporting 2 templates, one
for each kind of banner / usecase. This could make
components easier to reason with and maintain. For
now this commit sticks to one banner template as
coming up with a name without history / useage
guidelines is difficult, and we don't know that
users aren't already using headings with the base
layout - though we never intended it as far as I
can tell.

The custom theme demo has not been migrated to a Story
yet.
https://registry.origami.ft.com/components/o-banner@4.2.0#demo-custom-theme

I'm not sure there is value, and maybe harm, in showing
made up customised styles alongside those with brand/design
approval. Plus it's not clear how to re-create the style
without understanding Sass and inspecting demo code.
We probably want to have stories for customised components
at a later date, with improved guidelines around them
and demo Sass/JS pane. See related issue:
#370

The description of the demo starts "Although not recommended for
design consistency..." Let's not recomend it with a demo.
notlee added a commit to Financial-Times/origami that referenced this pull request Jan 10, 2022
Destroy Method:

Adds a `destroy` method to o-banner. This is used in the o-banner
Story to clean up the close button when re-rendered, which o-banner
dynamically creates on `init`. This is required to support the
`suppressCloseButton` Story control.

Hidden Controls:

It appears banner headings (headingLong/headingShort) should only
be used with the small/compact layout variants. Not with the default
banner style which is full bleed. However it is possible to use
Story controls to create that view.

`@storybook/addon-knobs` (deprecated) allowed dynamic knobs,
so we could hide the heading controls if the default layout
was selected. That's not possible with `@storybook/addon-controls`:
storybookjs/storybook#11984

I think that's probably a good thing. Support for
dynamic controls was worked on but not merge. It's
a poor experience when controls shift around.
storybookjs/storybook#13890

For now this commit hides the layout control on layout
demos, and hides the heading controls from the default
layout demo, to avoid showing the discouraged
heading + layout combination. However it is still
possible to select the base layout with heading on the
theme specific demos, so that the small/compact layout
can also be selected which is allowed.

This could be resolved by exporting 2 templates, one
for each kind of banner / usecase. This could make
components easier to reason with and maintain. For
now this commit sticks to one banner template as
coming up with a name without history / useage
guidelines is difficult, and we don't know that
users aren't already using headings with the base
layout - though we never intended it as far as I
can tell.

No Custom Theme Demo:

The custom theme demo has not been migrated to a Story
yet.
https://registry.origami.ft.com/components/o-banner@4.2.0#demo-custom-theme

I'm not sure there is value, and maybe harm, in showing
made up customised styles alongside those with brand/design
approval. Plus it's not clear how to re-create the style
without understanding Sass and inspecting demo code.
We probably want to have stories for customised components
at a later date, with improved guidelines around them
and demo Sass/JS pane. See related issue:
#370

No Custom Call To Action Demo:

https://registry.origami.ft.com/components/o-banner@4.2.0#demo-custom-call-to-action-layout

The description of the demo starts "Although not recommended for
design consistency..." Let's not recomend it with a demo.
notlee added a commit to Financial-Times/origami that referenced this pull request Jan 11, 2022
Destroy Method:

Adds a `destroy` method to o-banner. This is used in the o-banner
Story to clean up the close button when re-rendered, which o-banner
dynamically creates on `init`. This is required to support the
`suppressCloseButton` Story control.

Hidden Controls:

It appears banner headings (headingLong/headingShort) should only
be used with the small/compact layout variants. Not with the default
banner style which is full bleed. However it is possible to use
Story controls to create that view.

`@storybook/addon-knobs` (deprecated) allowed dynamic knobs,
so we could hide the heading controls if the default layout
was selected. That's not possible with `@storybook/addon-controls`:
storybookjs/storybook#11984

I think that's probably a good thing. Support for
dynamic controls was worked on but not merge. It's
a poor experience when controls shift around.
storybookjs/storybook#13890

For now this commit hides the layout control on layout
demos, and hides the heading controls from the default
layout demo, to avoid showing the discouraged
heading + layout combination. However it is still
possible to select the base layout with heading on the
theme specific demos, so that the small/compact layout
can also be selected which is allowed.

This could be resolved by exporting 2 templates, one
for each kind of banner / usecase. This could make
components easier to reason with and maintain. For
now this commit sticks to one banner template as
coming up with a name without history / useage
guidelines is difficult, and we don't know that
users aren't already using headings with the base
layout - though we never intended it as far as I
can tell.

No Custom Theme Demo:

The custom theme demo has not been migrated to a Story
yet.
https://registry.origami.ft.com/components/o-banner@4.2.0#demo-custom-theme

I'm not sure there is value, and maybe harm, in showing
made up customised styles alongside those with brand/design
approval. Plus it's not clear how to re-create the style
without understanding Sass and inspecting demo code.
We probably want to have stories for customised components
at a later date, with improved guidelines around them
and demo Sass/JS pane. See related issue:
#370

No Custom Call To Action Demo:

https://registry.origami.ft.com/components/o-banner@4.2.0#demo-custom-call-to-action-layout

The description of the demo starts "Although not recommended for
design consistency..." Let's not recomend it with a demo.
@stof stof deleted the improve-args-disable branch May 25, 2022 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants