How to configure "where" server side rendering tries to generate files

[rstudner]

So, I got a server side render would great on my dev box (woo hoo!)

I went ahead and pushed this to another environment and it fails.

The error is:

Showing /opt/web/apps/portal/app/views/investigations/_investigation_header.pdf.erb where line #7 raised:

Permission denied @ dir_s_mkdir - /opt/web/apps/portal/tmp/cache/assets/dev

Is it possible to configure the gem to not use this folder (this is it obviously deriving somehow) but instead use say /var/storage or any other location?

(the folder didn't even exist, in the first place -- but the entire tree is owned by root etc, and would love to simply write/read from a different location)

Thanks!

[rmosolgo]

Ah, I'd say this is really the same problem as this: #212

In production, server rendering should really use pre-compiled files, it shouldn't be compiling its own!

I don't know of a great workaround for this :( It's a bit tough since the complied asset can have a different name each deploy.

I think the right fix is to make SprocketsRenderer environment-aware (or make 2 renders, one for development, another for production). In production, it should read compiled assets only.

[rstudner]

Ahh. in this case, despite the production looking directory structure, it is actually running in a Rails development mode/environment.

So if an app is deployed in production mode with all assets pre-compiled etc.. then this probably would not be an issue? (and this is more an artifact of it being in 'development' mode, but deployed in a fairly non-normal/sane manner)

[rmosolgo]

Not quite -- actually it's a misbehavior on react-rails' part: even if you've precompiled your assets, it tries to compile them into tmp/cache/assets as if you were still in development 😢

[rstudner]

Hrm. So assets/dev and assets/production have to be write able for server side rendering to work in any environment?

[rstudner]

@rmosolgo Is there a simple explanation as to why that is true (note, just personally curious/trying to learn something. Don't take your time if it is a PITA to answer)

Regardless - in my specific case it is simply because the machine is setup poorly and root owns almost all the folders but doesn't run the webapp (and thus, write permissions).

[mchristen]

The behavior @rmosolgo is talking about occurs because of this line. Unfortunately that method of retrieving the contents of an asset doesn't respect pre-compiled assets, so the first time that content is requested sprockets will compile it for you and then hand over the content.

You can see a patch for this particular problem here. This allows react-rails to read the pre-compiled asset off disk instead of asking sprockets to compile it for you. Note that that repository and branch are outdated compared to reactjs/react-rails master branch, it is still on the React 0.13 release.

[rstudner]

@mchristen thanks for such a detailed response -- much appreciated.

That PR looks pretty small for sure (and doesn't seem to have code that would care about 0.13 vs 0.14)

[mchristen]

No worries, I was just pointing that out in case you wanted to use that fork directly and were expecting to get 0.14.

[rstudner]

@mchristen is there any reason that bit O code isn't an official pull request? I'm going to build a gem locally and try it out this morning once I get into the office :)

[rmosolgo]

^^ yes please! It'd be great to get a patch for this.

[rstudner]

I have a fork & branch off the latest master and so far everything is working. going to put it through some more paces before I submit the PR (and i'll make sure to credit the original author -- I didn't write a line hah)

[rmosolgo]

Here's a new approach for using precompiled assets instead of compiling them on the fly, happy to hear any feedback (or other things to keep in mind) if you have some! #430

[rmosolgo]

This should be fixed in the latest react-rails, please repopen if you're still having this trouble!