Merge with AltSchool Repo

[lifeart]

Is any way to get only one solution?

[lifeart]

https://github.com/AltSchool/ember-cli-react/issues/22

[alexlafroscia]

What exactly are you looking for?

I built this mostly as an experiment, borrowing a bit from the code in the AltSchool repo. If they're interested in updating their addon to support the decorator that I created, I would be happy to deprecate my repo and offer the code to them as long as I can maintain the commit bit on my code.

I'm not sure there's a whole lot to merge, though, as the approaches are fairly different. There are tradeoffs on both sides.

[lifeart]

@alexlafroscia, thank you for response! I'm just wondering why both repos looks alive, but have different approaches. I think it will be nice to have single 'react-components-in-ember' implementation to get it more featurable and stable. Can you please explain main differences beetween this repos? Is any way to create single repo from both repos?

[alexlafroscia]

Are there features or stability that you're finding lacking in either addon?

Both addons wrap a React component in an Ember one, the difference is just how.

My decorator approach takes a React component and wraps it in an Ember component within the component file, so that nothing knows that it's not just an Ember component.

The AltSchool approach leverages the resolver to achieve the same thing; when looking up a component, if the things returned isn't actually a component, wrap it in an Ember shim before rendering it.

There are some benefits on both sides

AltSchool approach:

• Seems to support functional components, which I don't support (yet)

My approach:

• Doesn't require Browserify (which would be easy to update on their end too, but would be a breaking change)
• Doesn't hide logic in the Resolver, where a user may forget about it
• Supports service injection (not clear if the AltSchool approach handles this)

Both addons:

• Allow JSX in JavaScript files (although mine also adds support for Decorators)
• Basically allow you to wrap a React component in an Ember one
• Handle passing block component contents to React's children (I borrowed the logic in my addon from them since this was hard to figure out!)

I don't know if there is really a huge benefit from one over the other but I personally like my approach better 🤷‍♂️ Unfortunately for me, they already have the ember-cli-react NPM package name so I have to pick something else if I want to publish to NPM.

[wmertens]

Does either approach have a solution for the having-dependencies-available-as-umd problem?

I'm thinking that it would be better if the react components do their own script loading, not via ember

[alexlafroscia]

Can you explain what you mean by that, @wmertens?

[wmertens]

Well, there's a bunch of tooling around React, like react-hot-loader, which requires e.g. webpack to run the build of the React components. Since Ember takes over the build process, that can't be used.

If the React app is just a script that you load and then get a global from, then Ember doesn't need to do any loading of React or the dependencies. So I'm now exploring how to integrate a fully self-contained React renderer.

[lifeart]

@wmertens https://github.com/lifeart/ember-ast-hot-load should hotreload any components

[wmertens]

@lifeart Hmm looks like that won't work with react-hot-loader though.

[lifeart]

@wmertens why you need react-hot-loader if ember-ast-hot-loader can hotreload react components inside ember?

[wmertens]

@lifeart react-hot-loader does extra work to maintain the internal state of the elements, so that forms, buttons, dropdowns etc don't get reset after reload. It uses the webpack module.hot API to do this.

I got things working like this:

• Create an entry point script that puts all react components on a global object
• adjust react-component to look for the components on that object; react is not imported by ember at all
• webpack builds the entry point as a separate js file
• Webpack-hot-middleware added as express middleware in the server file generated by ember g server

end result: ember dev also starts a webpack compiler that serves the react components and handles hot reloading.

still to figure out:

• hook into the deploy pipeline to build webpack and copy the result
• make some ember plugin that adds the middleware without having to do ember g server