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

setOptions resets to the defaults #5784

Closed
theKashey opened this issue Feb 27, 2019 · 6 comments
Closed

setOptions resets to the defaults #5784

theKashey opened this issue Feb 27, 2019 · 6 comments

Comments

@theKashey
Copy link
Contributor

Describe the bug

setOptions(options) would reset all not listed options to the default value.
basically, new options got merged with default ones, not the current ones.

To Reproduce
Steps to reproduce the behavior:

  1. add setOptions({anything}) to the .storybook/config.js
  2. open storybook with full=1
  3. Page would be loaded with full=0 (default)

Expected behavior
In 4-alpha it was working as expected, at the latest 4.1.12 it does not

Code snippets
If applicable, add code samples to help explain your problem.

https://github.com/storybooks/storybook/blob/master/lib/ui/src/modules/shortcuts/actions/shortcuts.js#L62-L65

setOptions({ clientStore }, options) {
    clientStore.update(() => {
      const updatedOptions = {
        ...defaultState.shortcutOptions,
        ...pick(options, Object.keys(defaultState.shortcutOptions)),
      };

this code was refactored in v5, and I am not sure is it a problem for the next branch.

Additional context
I need to open storybook fullscreen using a deep link.

@shilman
Copy link
Member

shilman commented Feb 27, 2019

cc @tmeasday

@tmeasday
Copy link
Member

tmeasday commented Feb 27, 2019

Wow I have zero memory of this code change but I can say it got completely refactored for 5.0.

My guess is there is a bit of a tension here between the use case @theKashey has (where the initial state set via query parameters needs to stick around, i.e. the state needs to be stateful), and the parameters API, where if one story sets and option and the next does not, we don't want the previous story's state to persist (i.e. we want it to be stateless).

I think I actually raised a similar point fairly recently with regards to the current v5 code so I'm not sure a solution has been found yet that satisfies both use cases. Do we want to try and fix in both branches?

@shilman
Copy link
Member

shilman commented Feb 27, 2019

@tmeasday Is this related? #5781

@tmeasday
Copy link
Member

@shilman - I don't think so. I imagine that one has something to do with refactorings in the story store that @ndelangen has made.

@stale
Copy link

stale bot commented Mar 21, 2019

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

@stale stale bot added the inactive label Mar 21, 2019
@shilman
Copy link
Member

shilman commented Mar 21, 2019

Closing this now that 5.0 is out. Please re-open if you're stuck on 4.x

@shilman shilman closed this as completed Mar 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants