Components with containers

[tomitrescak]

Loving the storybook! Great job, I already added it to several of my packages to showcase their interfaces.

I've bumped into an issue, when a component contains a container that snatches its own data. The data are taken reactively from Meteor source. What is the workflow to accomodat these types of components?

<Component>
   <ContainerOfAnother />
</Component>

[arunoda]

That's the kind of thing I'm looking at. With React Komposer, I use a way to disable the container functionality at all.
See: https://github.com/mantrajs/mantra-sample-blog-app/blob/master/.storybook/config.js#L4

I hope we can do a much better job as well.

[arunoda]

Looking for some ideas.

[MasterAM]

One option that comes to mind is stub the context.
Something like a more function-complete version of meteor-stubs could be useful for this.

Another idea is providing a parameter to ComposeAll that will include metadata about the component being composed. This could be a string, for the requirements of this set of functionality.
When in test mode, the composer could take a "stub composer" provided by the test and ignore the one in the original container file.

original container:

export default composeAll(
  'myComponentKey'
  composeWithTracker(composer),
  useDeps(depsMapper)
)(Component);

story file:

// will cause composeAll in the original container file to ignore the composers  
// provided to it and wrap the dumb component using testComposer
stubComposer('myComponentKey', composeWithTracker(testComposer)); 

Another option is to have composeAll return a function that (when in test mode) identifies the component sent to it and ignores the composers if a "test composer" was defined in the tests. This has the benefit of not requiring API changes.

In the previous example, this means importing the "dumb" component in the story file, defining a composer for it:

story file:

import dumbComponent from '../my_dumb_component.jsx';
stubComposer(dumbComponent, composeWithTracker(testComposer)); 

original container:

// Component is the same as dumbComponent, so the composer will use testComposer instead
export default composeAll(
  composeWithTracker(composer),
  useDeps(depsMapper)
)(Component);

[MasterAM]

I have implemented my last suggestion for react-komposer.

It works pretty well, as long as you don't need more than one composer type for the same component type (which seems to me like a reasonable expectation).

If I have a component that depends on a composition, I can enable the test mode and register a stub composer for it, which will override the original composer:

original component:

// components/my_component.js
import React from 'react';
import OtherComponet from '../containers/other_component';

class MyComponent extends React.Component {
  render() {
    return (<OtherComponet foo="bar" />);
  }
}

export default MyComponent;

If not stubbed, it may fail to get data, so let's create a stub:

// components/.stories/composer.js
import OtherComponet from '../other_component.jsx';
import {
  createStubComposers, setTestMode, compose
} from 'react-komposer';

const myStubComposer = (props, onData) => {
  // get data here
  onData(null, data);
};
setTestMode(true);
createStubComposers(OtherComponet, compose(myStubComposer));

and now we can use MyComponet in our story:

// components/.stories/my_component.js
import React from 'react';
import { storiesOf, action } from '@kadira/storybook';
import './composer'; // this is the file that registers the composer stub. import it before MyComponent
import MyComponent from '../my_component.jsx';

storiesOf('core.MyComponent', module)
  .add('default view', () => {
    return (<MyComponent />);
  });

@arunoda , any thoughts?

[arunoda]

@MasterAM overall, this seems like a good idea.
Send a PR and let's discuss.

[MasterAM]

@arunoda, PR sent.
Currently I use some fixtures located in a file under .stories as the alternative data source for the composer stub. The composer stub itself is set up in another file inside the .stories directory.

In the stub setup file I import those fixtures and the base component, use the fixtures in the stub composer function and call createStubComposers with the base component and the stub.

It is also possible use a completely different composer with the same component later on (if another component is using a composition that includes it) by overriding the stub composer for it. It can by done by calling the createStubComposers again with the same component and a different composer.

It all depends on the identity of the composer at the moment of invoking the function returned from composeAll(). The invocation is usually done in the file in which the composition is defined, so the file that sets up the stub should be imported before the actual composition file is imported.

[gavriguy]

you might want to try https://github.com/gavriguy/react-indie which has some similar concepts to react-komposer but takes a different approach for handling data defaults, data loading and errors. it lets the component itself deal with the ui of all of the above making it a perfect fit.

it even uses storybook to showcase how the component works.

(note: im the creator of react-indie)

[arunoda]

@gavriguy great. And you can publish your storybook to GitHub pages.
Checkout react-cdk for this. It has the sample code to do it.

[ihealthdavid]

@MasterAM Some of us are following the Mantra spec, which usually has 2 composer types for each component type, so I had to use a different approach.

@arunoda It doesn't look like https://github.com/gavriguy/react-indie would work well with mantra-core either.

I added a composeAllWithStub function on top of the setTestMode. Will submit PR shortly.

[ihealthdavid]

I run @MasterAM 's setTestMode(), then

export default composeAllWithStub([
  composeWithTracker(composer),
  useDeps(depsMapper)
],[
  compose(composerStub),
  useDeps(depsMapperStub)
])(Component);

Please check mantrajs/mantra-sample-blog-app#110 to see a working example.

[MasterAM]

@ihealthdavid
AFAICT, You can set the composers however you like for the original component, so you can use the Mantra spec (as I do, too). What prevents you from specifying as many composers as you like for a component? Can you show a simple example where it fails?

I created createStubComposers the way I did because I did not want to do "scaffolding" for tests in the application code.

@arunoda It does not look like PRs for ReactKomposer are getting much love. Any chance to change that?

[arunoda]

@MasterAM I'm taking all of them in this week. Stay in touch.
Sorry about the delay.

[arunoda]

Hi all, I've looked at all these options. They are great.
Anyway, I come up with something which looks like simple to me.
So, I implemented that. See: https://github.com/kadirahq/react-komposer#stubbing

I hope that's more than enough.

[MasterAM]

Thanks, @arunoda; this looks fairly elegant and useful. I will implement it soon in one of my apps which uses StoryBook and let you know how it went. 😄

[arunoda]

@MasterAM great.

[sokki]

Is there a way to deal with containers-in-component without react-komposer? We use Meteors createContainer and ran into the same problem ...

[arunoda]

Yes. There is a way. Check Kadira Voice in few hours.

[arunoda]

@sokki See: Stubbing React Containers for Testing

[arunoda]

I think we could close this.

[arunoda]

Add ref: storybook-eol/getstorybook#1

[tomitrescak]

Guys, sorry for reviving this thread, but I am interested in your opinion. What really works for me for unit testing is to load all all components and containers as part of the module (mantra-style). Therefore module contains: { actions, components, modules }.

Then, in the component I load the components from the context from the given module. Such as:

export conts Component (props, { modules }) => {
const { Markdown } = modules.core.containers;

return <Markdown text="A" />
}

Component.contextTypes = {
  modules: React.PropType.object
}

Do you see any issues with this approach? It makes unit testing a breeze.