react-rails
react-rails copied to clipboard
reactjs
Better handling for compilation errors
Help us help you! Please choose one:
- [ ] My app crashes with
react-rails, so I've included the stack trace and the exact steps which make it crash. - [ ] My app doesn't crash, but I'm getting unexpected behavior. So, I've described the unexpected behavior and suggested a new behavior.
- [ ] I'm trying to use
react-railswith 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. - [x] I have another issue to discuss.
Can we catch ProgramError and raise another error with more details here? Something like React::ServerRendering::PrerenderError. Now compilation error can be something like setTimeout is not defined (yes, I know that is polyfilled now, but just an example) and it's all so we don't know where the problem is.
What do you think?
Looks like this was done sometime in the past. https://github.com/reactjs/react-rails/blob/master/lib/react/server_rendering/exec_js_renderer.rb#L22 This does catch ProgramError and re-raise as PrerenderError. 👍 Thanks for the idea.
Hi @BookOfGreg I think, I wanted to handle it in initializer here. IIRC, compile was raise ProgremError when some of npm packages wanted to access properties of window in SSR.
Aha, it's tricky when the code moves over time. That's clearer.
Would you like to help by look into a PR around this feature? It sounds useful and there are a LOT of folk reporting issues when they're using window server-side.
I'm not sure if it is doable. Now we call JS renderer with a JS code as a string so we lose any information about the location of the code.
That's true but you wonder if there's any source_map equivalent. I've not seen anyone do it in exec_js so far. May close this as upstream if we're already surfacing everything that exec_js does.
Hi both, I've never used this gem but I'm about to so I thought it would be a good idea to see how it works internally. is this issue still need to be worked on ?
Yep. This is an issue with how ExecJS outputs JS errors, and with how we interpret them when we do. Since this gem mostly integrates other bits (execjs with webpack or sprockets, with controllers and helpers) plumbing together the different components so true errors come out the other end is easy to do at a basic level and hard to do if for instance webpack decides to have code splitting with no sourcemap enabled or via dev mode.
Any progress to get a simple case going would be very welcome, and then I can just disable it for the edge cases I know of so we won't have to deal with those.
@BookOfGreg, is there a place where we can talk about this please ? like Gitter, Hangouts or something else
@NeimadTL @BookOfGreg, Do we have any updates on this? Closing the issue. We can reopen it anytime or create a new one.
