Providers. Custom data loader, router

[bdefore]

With #55 UR now supports custom root components.

Custom root components createForServer and createForClient methods now receive an additional parameter providers of type array that contains strings matching libraries the user would like the root component to integrate. With this PR, universal-redux also provides built-in support for enabling either async-props or redux-async-connect.

The API feels a little ... loose. But it has room to grow for potentially adding router5 support, or Relay/Falcor, and I'd rather not be too proscriptive at this point about what pieces users might want to include.

A downside is that UR bloats dependencies for each option it supports in the future. A longer-term solution could include exposing a provider API and expect users to give UR these dependencies themselves.

@aam229 Curious what you think about this addition.

Also. Is providers the right name for this functionality? integrations? options?

[bdefore]

This was unrelated to the PR, redundant/noisy logging.

[aam229]

I really like the idea. I'll have a better look when I get home.

[aam229]

@bdefore that just gave me an idea. We could introduce the concept of plugins. If we implement something like #56, plugins would define the equivalent of the hooks.js file. The hook config property (which would be renamed to plugins) would become an array of strings. These strings would be resolved to js files as follow:

• Using the string as a path: require(projectPath + plugin)
• Using the string as a module name: require('${projectPath}/node_modules/universal-redux-plugin-${plugin}')

If you follow this logic, we could take the code in this PR and turn it into 2 plugin modules:

• redux-universal-plugin-async-props
• redux-universal-plugin-async-connect

In config.js, you would use these plugins by doing:

export default {
  plugins: ['async-props'] //or
  plugins: ['async-connect']
}

It's actually not that much work and I don't mind doing it if you think it's a good idea. It would also allow this project to remain pretty clean while allowing people to publish module to tailor its behavior.

What do you think?

[bdefore]

@aam229 I like the approach you're describing and it would be great if you could take a stab at it. The only think I'd mention is to follow the naming convention of the library and name them i.e. universal-redux-plugin-async-props rather than redux-universal-plugin-async-props

[aam229]

@bdefore haha of course my bad, I keep messing up the order. I'll start working on it then

[sompylasar]

Please be aware that webpack statically analyzes the require calls and will choke on the dynamic requires (with expressions instead of static strings).

[aam229]

@sompylasar thank you for the thought, I ended up adding them to the entry.main array in the webpack config so that they get included.