installing components from npm about idyll HOT 8 CLOSED

Nice! thanks for asking me to join the conversation :)

I must admit I love the first option. It reduces the burden on the end user side, eases adoption, at the cost on some time investment in tooling and "magic".

Maybe the workflow could be even more simplified:

For the idyll module developer:

• may use a prefix (eg. idyll-component-*) as a convention, because it's nice for branding
• should use a keyword (eg. ”idyll-component”) as a convention, to be listed in search results

For the end user:

• list idyll modules using some idyll list command (see https://github.com/nodesource/npmsearch#api + https://npmsearch.com/?q=keywords:idyll )
• install the component using npm i some-module-name
• use [SomeModuleName /] in the .idl

Observations:

• in this scenario the Idyll component name (or just the default Idyll component name) would be inferred from the Node module name using the same convention as in React for dom props (ie. package name in hyphen-case -> idyll component name in UpperCamelCase).
• Developers would have a strong incentive to use the correct idyll keyword in order to be found in search results
• idyll would have to try to require the module to check if it's ok (or do whatever operation Idyll needs)
• Idyll could be smart and try to automatically wrap (convert) “non-native idyll” React modules when the user try to use them
• bonus: [MonoRepo:Component1 /], [MonoRepo:Component2 /] etc? for those who want to store multiple components in the same master package/repo. It could work of they follow some convention (eg. name sub folders the name of their Component, use an index.js..) (just a thought!)

from idyll.

Thanks for the comments, these are super helpful for thinking through everything.

@jbilcke In the case that you npm install idyll-component-some-thing do you imagine the prefix should be dropped so that it is invoked with [SomeThing /]?

Idyll could be smart and try to automatically wrap (convert) “non-native idyll” React modules when the user try to use them

I think this would be pretty hard to do without an explicit listing in package.json. The reason being that its hard to tell what module maps to a component vs. any other kind of library. That would lead to anything in node_modules being a candidate component which I think we should avoid.

The thing that I'm concerned about in addition to making it as friendly as possible is trying to make sure that it doesn't do anything surprising, and I worry with the first option we could be getting too close to that, especially with all the name mapping.

At the moment I am leaning towards (2) for the following reasons:

• Even though its potentially more work for the end user I think its conceptually simpler
• we can add an idyll install shortcut to minimize how much extra work it really is.
• I think we'd have to add the package.json field to support arbitrary react components anyways, so even if we wanted to add some automated resolution in the future this wouldn't be wasted work.

That being said, feel free to push back, because I agree that it would be really slick to have everything just resolve automatically.

Also, @jbilcke see #30 re: your last point. I agree that will probably prove to be very useful

from idyll.

I think that would be a great compromise!

Combining the safety (and accuracy - my idea would also have caused naming collision issues) of the package.json with the ease of use of a small command (idyll install) to help add components in it.. that would be the best indeed :)

(btw: I didn't see #30 at the time, but the dot syntax is cleaner 👍 )

from idyll.

/cc @rreusser @jbilcke

from idyll.

One advantage of the second option is that you can install and use any react components (or similar), they don't have to be explicit idyll components.

It is more work for the end user, but we could make it easier by providing some shortcut for it

idyll install componentA:idyll-component-a

and have that automatically updated package.json

from idyll.

Ooh. Yeah. I like parts of both. The two that I like are scanning for explicit triggers in the package.json and explicitly defining things in your package.json. The reason I like those is that it's less magic than relying on npm module names, which it seems a bit unfriendly to constrain with no escape hatch. If I had to take only one, I guess I think listing the component paths in your package.json is more flexible as you pointed out. The solution I'd use is both since they're not mutually exclusive. But I think a far better solution is to actually pick one. 😬

from idyll.

I'm not familiar with the compiler (yet) so forgive me if this is ignorant of real world constraints. I think it would be wise to optimize for the end user's experience since, almost by definition, they will outnumber authors. To that end, could Idyll look in node_modules by default if listed component is not found in the components directory?

End user

1. npm install secret-idyll-comp
2. [SecretIdyllComp /]

Idyll

1. Sees [SecretIdyllComp /]
2. Does not find components/secret-idyll-comp.js
3. Looks for node_modules/secret-idyll-comp

I think the component naming and keywords make sense and should be encouraged, but avoiding them as a hard requirement would be nice.

from idyll.

closed in #32

from idyll.