Help us help you! Please choose one:
react-rails, so I've included the stack trace and the exact steps which make it crash.react-rails with another library, but I'm having trouble. I've described my JavaScript management setup (eg, Sprockets, Webpack...), how I'm trying to use this other library, and why it's not working.Rails 5.1 is branching out from the sprockets asset pipeline by including support for webpack and yarn via webpacker. I've really enjoyed the simplicity of react-rails, but there has definitely been pain when wanting to import pre-made React components from NPM. It would be amazing if react-rails on Rails 5.1+ could solve that pain point using the webpack/yarn support.
Maybe some would say what's the point of the gem at that point, but I think the react_component helper with the prerender support makes it worthwhile at least.
Just wondering if it's on your radar at all?
Yes, I've been thinking about the same split! If you use webpacker, then you don't need the JSX support offered by this gem, but the view helper & server rendering are still valuable. I was thinking of looking into it after Rails 5.1 was released. Have you taken webpacker for a spin yet??
I did a little bit - I installed webpacker over the weekend in a Rails 5.0 app (since it currently is compatible with 5.0), but haven't had much chance to mess with it beyond just installing it as I'm not very familiar with webpack (several months ago after much trial and error I got a very basic webpack setup working for running Elm but that's it).
I think I'll have some time this weekend to mess with it further and see how hard it is to migrate my existing react-rails components over and hopefully try installing some components from npm.
@rmosolgo @abevoelker I'll be adding webpacker support for React on Rails within the next couple of weeks. Webpacker is essentially adding some asset helpers that will make it easier to load webpack files from Rails views. This topic is sort of orthogonal to the react-rails and react_on_rails gems other than we can create deployment files easily without going through the asset pipeline. Webpacker is a bit special in that we're going to make it depend on on Webpack v2.x.
Played with this a bit in hopes of getting server rendering working and found that to get this to work, we're going to need a custom server renderer that can point at pack files living outside sprockets and its manifest.
Something like:
config.react.server_renderer = React::ServerRendering::WebpackerRenderer
config.react.server_renderer_options = {
files: ["mywebpackpack"]
}
I wasn't able to quickly hack together a renderer that would pull from files written by webpack-dev-server, but here's what I found.
We can use Webpacker::Source.new("mywebpackpack").path to get the path (or URL if on another domain/port) to the asset (it can come from webpack-dev-server on another port, can be /packs/mywebpackpack.js in development, or a digested version in production).
Don't know if I'll have time to dig further on this any time soon, but figured it couldn't hurt to share where I landed so far.
I started trying to add webpacker support for Rails 5 and Rails 4.2 (Webpacker 1.1 supports both)
But I can't seem to get the appraisal gem to run the set that I want, current progress is commenting out rails_3.2 which seems to be broken.
https://github.com/reactjs/react-rails/compare/master...BookOfGreg:webpacker-manifest-support?expand=1
Thanks for sharing your work so far!
It's free week at @planningcenter so I'm digging in now. I've outlined my goals on #677, feel free to chime in there if you have any suggestions. Hopefully we'll have a solid webpacker story by Friday :)
@rmosolgo Been using it in one of my internal projects, just to save you from a Gotcha, we changed from ::Webpacker::Configuration.output_path.parent.join( to Rails.root.join('public',.
The reason being if you change the config.entry in Webpacker's Path.yml, it changed config.output_path to have the entry twice so it would not be able to find the output location on disk.
eg:
#path.yml
config: config/webpack
entry: assets/packs
output: public
node_modules: node_modules
source: app
extensions:
- .js
- .jsx
irb(main):001:0> ::Webpacker::Configuration.output_path.parent.join(::Webpacker::Manifest.lookup('components.js')[1..-1])
=> #<Pathname:/Users/bookofgreg/source/project/public/assets/assets/packs/components-ad9db5484191f035fa98.js>
irb(main):002:0> Rails.root.join('public',::Webpacker::Manifest.lookup('components.js')[1..-1])
=> #<Pathname:/Users/bookofgreg/source/project/public/assets/packs/components-ad9db5484191f035fa98.js>
馃槄 thanks for the heads-up!
I opened an issue about the pack path: https://github.com/rails/webpacker/issues/231
@BookOfGreg Can you not do this?
default: &default
config: config/webpack
entry: entries
output: public
manifest: manifest.json
node_modules: node_modules
source: app/assets/javascript
The idea behind entry option is to change the entry folder name to anything else (packs, bundles or whatever). The source folder controls the path to javascript app.
irb(main):001:0> ::Webpacker::Configuration.output_path.parent.join(::Webpacker::Manifest.lookup('app.js')[1..-1])
=> #<Pathname:/Users/gaurav/webpacker-example-app/public/entries/app.js>
irb(main):002:0> ::Webpacker::Configuration.output_path.parent.join(::Webpacker::Manifest.lookup('app.js')[1..-1]).to_s
=> "/Users/gaurav/webpacker-example-app/public/entries/app.js"
Would this work for you?
Most helpful comment
Thanks for sharing your work so far!
It's free week at @planningcenter so I'm digging in now. I've outlined my goals on #677, feel free to chime in there if you have any suggestions. Hopefully we'll have a solid webpacker story by Friday :)