Compile to static html but allow some custom JS to be proccessed

[jannisg]

I'm just trying to move my static html workflow away from Ruby based tools like Middleman to NodeJS based tools like Gatsby and I am having trouble trying to work out if there is a way to:

1. Compile React modules to static html files (supported by gatsby using the noProductionJavascript option)
2. Allow some JavaScript to still make it through the compile pipeline but still end up with a non-react dependent static html output overall.

Use case being that I occasionally do a pretty basic design to HTML conversion job for ad agencies so they expect me to deliver:

1. Static .html files for each "template" they had designed
2. Within their templates if anything requires JavaScript (modals, overlays, etc), those bits be supported and shipped as part of a JS bundle for the static app.
3. Static assets (fonts, images, etc) be compressed
4. Static output has usable hrefs that they can click through to navigate the templates
5. The compiled HTML source should be neatly formatted and uncompressed

I believe Gatsby natively supports 1, 3 and 4. Point 5 is probably doable too but I am struggling to understand if 2 is possible as the noProductionJavascript seems to strip all JS out so I am not sure if I could for example have a file that is still being bundled containing custom app JS but not any of the react stuff.

Would be great to hear if this use case is supported somehow already or if I am perhaps looking at the wrong too for what I need to do :)

[KyleAMathews]

It's perhaps possible but could I ask why? You could treat React as a dumb template layer and do old school jQuery tricks like adding classes to React components and then attaching javascript to that. But part of the beauty of React (and why Gatsby is so nice) is that you don't have to do this — JS enhancements are always easily available without any of the painful ceremony jQuery required.

Gatsby + React don't add much overhead — less than 100kb normally and with the coming Gatsby 1.0 even less.

You'd have to ship that much anyways just to add jQuery + some sort of modal/overlay plugin thing anyways so if you're using Gatsby I'd suggest just jumping all the way in and using React + React models/overlays (which there's plenty).

[jannisg]

I agree, it's not an ideal use case by any means, I guess the main reason for this even being a use case at all is that these agencies are used to getting static assets this way and since they usually take the static assets I deliver to them and then put them into their own .NET (or other backend tech) backend system and template renderer they really just want to dump some HTML into their own systems' template engine and put a global script somewhere so that the JS "works".

As I understand it, implementing the non-static (noProductionJavascript=false) output into a different templating system would not work right or at the very least would require the integrating backend dev to understand react components and server side rendering of react?

[KyleAMathews]

Oh interesting. Yeah — React components aren't at all like normal templates you find in other static site generators. Components have to be run within a JS environment so data has to be loaded into the site in order for React to run. Also React components compose and pass data down to each other. .NET wouldn't know how to handle it so there'd be no way to let a backend system pump data through React components like you're describing.

Currently with Gatsby 0.x you'd need to pull data from their systems and add it to the Gatsby site as JSON files and build the site from them. With 1.x, I'm adding a new GraphQL data layer that'd let you hook up a site directly to backend systems instead of needing to write it to disk each time. I'd be curious to hear your feedback on this — #420

[jannisg]

Yea I think the GraphQL data layer to build a more dynamic integration with legacy systems and APIs would be awesome (#420). One thing I didn't quite get from your #420 issue description is how this would deal with active backend systems, i.e. the author publishes a new article in WordPress or whatever legacy system they use and this post now being available in the static site. As far as I understood the data querying and json building would happen only at compile time so new content published after the initial compile would not be available on the static site. Now, this makes perfect sense given we're talking about a static site builder but in light of this ticket where the agency has existing .NET CMS systems for instance it wouldn't really help I think 😄

I would love to use React in these little static jobs but at the end of the day I would only use them as dumb components so I can define say a shared <Header /> component to output a template of HTML/JSX so I can reuse this across the 16 templates that need to eventually be statically output as .html files. So really, I wouldn't be leveraging much if anything from React other than being familiar with React and using it as a basic template/partials system.

So in this particular use case —seeing as it's a rather antiquated use case in the first place— I might have to settle on a more "traditional" dumb template system like Roots.cx which I just stumbled upon which seems to be just a basic layout/partials templating system with some JS compilation pipeline built in and use that to generate static assets to be handed over.

[KyleAMathews]

For integrating with a legacy system, I'd anticipate most people would setup a manual or automatic build trigger e.g. someone saves a change (or a change has worked it's way through a workflow system) and at that point whatever you're using to build Gatsby would be triggered to rebuild with the latest content and redeploy the site.

Gatsby is quite quick to build so most sites should rebuild in < 30 seconds (and there's plans to improve that further).

[jannisg]

Yup, that makes perfect sense. :)
I'll close this issue seeing as the discussion has clarified the original question about this specific use case. Thanks for being so responsive!

[grundmanise]

@jannisg What you ended up using?