2.0 default blueprints

[anithri]

Lets talk ideas for default blueprints.

The are the current ones, they'll need to be updated some. for instance PropTypes moved to it's own package.

• smart
• dumb
• blueprint
• blueprintrc

These are related to each other, and may belong in a blueprints-redux package.

• duck
• form
• redux - store, reducers setup
• concern - duck's big brother that adds files for shapes ,selectors, container HOC sagas?

[anithri]

• Smart + life cycle methods declared.
• PureComponent
• stateless & functions as components
• selectors
• HOC's

[jamesr73]

I might argue that the core be restricted to:

blueprint blueprintrc blueprint-module

And a companion module for defaults, that could auto install core if it was installed, would provide the base react/redux blueprints.

It's worth considering renaming the existing defaults such as smart and dumb to make them sit well in a larger ecosystem of shared blueprints. Something like:

smart => redux-connected dumb => react-component form => redux-form

They could always be shipped with aliases that retain access to the smart & dumb names. #110 provides the ability for users to assign aliases to any blueprint in the rc file, so they are easy to customise. (aliases in rc always override aliases in the blueprints)

Differences like stateless, stateful, life-cycle methods could be implemented as distinct blueprints or by using options on a smaller set of blueprints.

[anithri]

I don't mind having the react specific "default" set of blueprints in an external package. But I think it's really important to have a set of usable blueprints to show the user the first time they try it. And that those default blueprints collectively demonstrate all of the abilities of the system. But I'm totally behind keeping those in a separate package.

[anithri]

And I think we should try and have a couple of different default packs, would hate to have user not use it because they thought it for a specific framework