container components vs composers...

[makstr]

@arunoda so I have been thinking about the container components approach and realized that sometimes the containers could be abstracted to more universal composer functions and later combined in a more 'on demand' manner.

Take a look at the _colors module

I have the following structure:

• components/collection.jsx - a wrapper component rendered by router to lists all colors
• components/single.jsx - a wrapper component rendered by router to show a single color
• components/add.jsx - a wrapper component rendered by router to add a new color
• components/edit.jsx - a wrapper component rendered by router to edit a single color

I also have the data rendering / functional components:

• components/_collection.jsx - renders collection of colors
• components/_single.jsx - displays the color data
• components/_form.jsx - a universal form

and instead of using containers I have a abstract list of composers function:

• composers/collection.jsx - retrieves collection of colors
• composers/single.jsx - retrieves a single color
• composers/add.jsx - delivers a submit action for update operation
• composers/edit.jsx - delivers a submit action for add operation, and combines the composers/single.jsx to provide initial data

/_colors/composers/colors/edit.jsx:

import {useDeps} from 'react-simple-di';
import {composeWithTracker, composeAll} from 'react-komposer';

import {singleComposer} from './single.jsx';

export const editComposer = ({context, clearErrors}, onData) => {
  const {LocalState} = context();
  const error = LocalState.get('_colors.SAVING_ERROR');
  onData(null, {error});

  // clearErrors when unmounting the component
  return clearErrors;
};

export const depsMapper = (context, actions) => ({
  submitAction: actions._colors.update,
  clearErrors: actions._colors.clearErrors,
  context: () => context
});

export default (component) => composeAll(
    composeWithTracker(singleComposer),
    composeWithTracker(editComposer),
    useDeps(depsMapper)
  )(component);

/_colors/components/colors/edit.jsx:

import React from 'react';
import Sidebar from './_sidebar.jsx';

// import Container from '../../containers/colors/edit.jsx';
import dataComposer from '../../composers/colors/edit.jsx';
import Component from './_form.jsx';
const Container = dataComposer(Component);

export default class extends React.Component {

  render() {
    const {_id} = this.props;
    return (
      <div className="bs-docs-section clearfix">
        <div className="row">
          <div className="col-md-3">
            <Sidebar />
          </div>
          <div className="col-md-9">
            <Container _id={_id}/>
          </div>
        </div>
      </div>
    );
  }
}

view / composer	collection	single	add	edit
collection	X
single		X		X
add			X
edit				X

Of course if you want ready to use container components nothing is stopping you and they will be even simpler to write given a set of well designed composer functions.

/_colors/containers/colors/edit.jsx:

import dataComposer from '../../composers/colors/edit.jsx';
import Component from '../../components/colors/_form.jsx';
export default dataComposer(Component);

Benefits?

• DRY, you write a single data fetching composer function and employ it multiple places, eg in single view operation and edit operations
• I also have an auth composer which empowers some of the user related functionality, so If I need to display the user's first, last name all I need to do is use the composer function in a wrapper

What do you think?

[arunoda]

I think this is a big topic we should discuss. So, I defer this until we ship module system.

But, If it's the composers directory, we should only place the composer function only. May be these should go into the library directory.