storiesOf().add() reads fn.name if only 1 arg provided

[nfcampos]

This change helps when the function provided to .add() is reused in the same file for eg. tests, so it is defined outside of the call to .add() and assigned to a variable. The story takes the name of the function/variable.

[arunoda]

Okay. I am fine with this. But I wanna know really how you use this.

May be that helps me to do the documentation.

[nfcampos]

Basically my use case is that I want to use the same 'stories' (ie. components + props) for storybook and for testing.

like this:

import React from 'react'
import test from 'blue-tape'
import {shallow} from 'enzyme'

import StepHeader from '../step-header'

const props = {
  file: { name: 'name of the file' },
  name: 'name of the project',
  table: {
    length: 1234,
    columns: { length: 56 },
  },
}

const tableAsValue = () => <StepHeader {...props} />
const tableAsPromiseState = () => <StepHeader {...props} table={PromiseState.resolve(props.table)} />

storiesOf('StepHeader', module)
  .add(tableAsValue)
  .add(tableAsPromiseState)

test('<StepHeader /> table as value', t => {
  const wrapper = shallow(tableAsValue())
  t.true(wrapper.contains(props.name))
  t.end()
})

test('<StepHeader /> table as PromiseState', t => {
  const wrapper = shallow(tableAsPromiseState())
  t.true(wrapper.contains(props.name))
  t.end()
})

[nfcampos]

Do you have any concrete plans for how to integrate stories with tests? From my limited time using storybook it seems that another missing piece is for action('clicked the link') to work like a spy (ie. keep track of the nr. of calls,etc. and make that accessible as .calls(see eg. the spies in https://github.com/mjackson/expect#spies)

[arunoda]

Okay.

About tests. Both tests and stories are two different things.

• tests - check the functionality.
• stories - check the UI/UX and develop it.

Stories are usually create by designers (for anyone who play that role). Then developers writes tests for the functionality. That's to make sure, designers do not break the app.

That's how we think about testing.

[arunoda]

Hey, we talked about this PR. Although I like it, this violate one of our API design goals. Which is:

There should be only one way to do something

This violate that.
But it's totally possible for you to create a simple wrapper. May be publish that to NPM.
I can link to that project from the docs.

Finally, really appreciate working on this.

[nfcampos]

Thanks for considering it. In the end this was nothing more than a convenience. About tests, I know tests and stories are different things, my point is that, at least for me, they usually end up sharing one thing, the props passed to the component. Since stories are little more than props + component, I'm thinking it suits my needs for the tests to operate on the stories

[arunoda]

@nfcampos yeah. That's a good idea too.
Try to play with it and let's start a chat on a different thread on how things work.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 950d0f2. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 1 target

• nx run-many -t build --parallel=3

---

Sent with 💌 from NxCloud.