-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Embedding CRA created SPA into a bigger CMS #1678
Comments
What you describe sounds like a reasonable way to do it. We don’t really strongly support this use case, and if you need further adjustments, you might want to We might want to support |
@gaearon I can PR this feature 😛 |
@jnachtigall if you add In some cases you might need to adjust the set / adjust the homepage setting in package.json file. |
I use CRA for this use case pretty heavily. I generally don't use the built index.html file at all. I have a shell script that runs at the end of When I dev I just make a hard copy of the page I'm going to be doing the app inside, like you described. If you want to bring the built version of CRA back into your main apps dev system it would be best to eject and add a command like |
You can do this without ejecting. Something like
|
Thanks for all the comments, much clearer now 👍
I think, yes, a bit. I guess the
This would make postprocessing/embedding into some CMS template easier. What do others think?
I guess this is the main point: You need some postprocessing in package.json like: Obviously, this |
Hmm, two questions regarding integration into a CMS:
|
|
@gaearon After building two React Apps for two different kind of CMS (one Java based for govermental usage, another PHP based) I found that the biggest pain point where the file hash numbers. What I did: Like others suggested in this thread I copied the main..js + main..css from CRE to main.js and main.css of the CMS. The files' hash numbers make this unnecessarily cumbersome. For one, the sourcemaps do not work anymore. If you have media files, e.g. images which also have the hash in the filename, it is even more cumbersome. Even worse, my companies build servers run on Windows (I know, facepalm), so basic Unix tools like Long story short: If there was an option for disabling the hash numbers in the first place like asked for in #1005 this would greatly help. |
@jnachtigall You can read |
@viankakrisna Yes, I know, but the hassle comes afterwards. In the CMS we use it is easy to "mount" (register/integrate) a CSS or JS file known by path and file name into the CMS. This is how we do it when we build with grunt/gulp which output simple main.min.js or main.min.js. It is much harder to this when the file name is not known in advance. This requires knowledge and skills regarding the CMS' API and CMS scripting language (So I need to setup meetings with the backend devs, who asked me why we cannot do it like with grunt/gulp? Communications...). For instance, your comment links to a PHP based post-processing script. This would look very different for a java, python or whatever based CMS. Usually, it would be even different for each CMS because they all have different APIs for "mounting" (integrating) external JS/CSS files. Moreover, even when you've done the mounting, e.g. like outlined in your comment. Then still, the path to the source map file is broken. I'm not saying that it is not possible. It is just cumbersome. And the root cause solution to this would be if the hashes were not generated in the first place (if CRE had an option for this). |
I'd say we just don't intend to support this use case. |
My app should be part of a bigger CMS which has header, navbar, sidebar, footer elements. The app will be just some
<div id="root" />
within the main content. I do not really know how to set this up with CRE for development and live deployment?For development, so far I have just create a rather big index.html in
public
directory. Theindex.html
includes (hand copied) the header, navbar, sidebar, footer markup as it comes from the CMS and also some of the CMS' css files. For development it's ok (we do not change a lot on the CMS right now, so not much to keep in sync).For putting the app into production (live), I would like to just include the
<div id="root" />
into one of the CMS's content templates and add links to the build CSS and JS files that are underbuild/static/
. Do you think this is the best approach to be taken? Any side-effects I cannot think of at the moment? For instance the index.html for live would need to be cut down to only include the<div id="root" />
and thescript/link
to include the hashed CSS/JS static files, nothing else. And I would not know how to have a different public/index.html for development and production?The text was updated successfully, but these errors were encountered: