Be able to resolve arbitrary modules

[geoffp]

We should able to provide any mapping we want of module names requested in es2015 syntax to modules delivered to the code. The first step should be registering component-patterns as pattern partials so that component-patterns can include each other with an import and JSX syntax.

Syntax options

We may or may not able to support more than one of these.

One module per pattern, native naming

import Button from 'button';

• PRO: 100% portable outside Pattern Lab (holy grail option)
• CON: Not very atomic-y at the code level, though it would still be atomic in presentation in PL if directories are organized that way

One module per atomic type, native naming

import Button from 'atoms';

• PRO: more atomic-y, reads the best IMO
• CON: imposes some restrictions on how code needs to be organized in an environment outside Pattern Lab

One module per pattern, atomic naming

import AtomsButton from 'atoms-button';

• PRO: wow, such atomic
• CON: your production components need to be named in atomic nomenclature, least portable option

Module loading options for runtime execution of patterns

We need to put something on the rendered pattern page to enable runtime execution of components, which is a must.

Bundle everything together on the pattern page with Webpack

This feels to sort of brute-force-y to me, but it could work.

• PRO: Webpack is familiar to most React devs
• CON: each generated pattern file would contain its own copy of every module and external dependency imported by its component-patterns. Not a dealbreaker. Is this somehow a pro also?

Load modules with systemjs or similar

I'm currently drawn to this one.

• PRO: allows async loading of modules, opening up the option of loading external dependencies from CDNs
• PRO: would keep generated code small

[bramsmulders]

Hi @geoffp, long time since there has been worked on this. Here in out company we're very interested in a react engine for patternlab where we could share the react templates with our backend system.

Were currently working in a fork to make this possible. Do you have any preference how you wanted to build this?

[geoffp]

@bramsmulders - for now, I'd like to make module resolution as flexible as we can without creating too many ambiguities, because I suspect every user will have their own preferences. This thing you pointed out looks very promising.

I'm also okay with the current practice of creating a module bundle inlined on the rendered html page that pattern lab shows you. That page is not really a consumable asset, so maybe it doesn't matter much, as long as it works.

The way we produce consumable assets (if at all, maybe consuming projects can just refer to the pattern files in patterns/ as-is) is a different matter.

[bramsmulders]

Hey @geoffp, This pull request is adressing this issue:
#2
It works with atoms-button syntax. check it out!