Skip to content
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

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

Closed
jannisg opened this issue Sep 26, 2016 · 7 comments
Closed

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

jannisg opened this issue Sep 26, 2016 · 7 comments

Comments

@jannisg
Copy link

jannisg commented Sep 26, 2016

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
Copy link
Contributor

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
Copy link
Author

jannisg commented Sep 26, 2016

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
Copy link
Contributor

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
Copy link
Author

jannisg commented Sep 26, 2016

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
Copy link
Contributor

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
Copy link
Author

jannisg commented Sep 27, 2016

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!

@jannisg jannisg closed this as completed Sep 27, 2016
@grundmanise
Copy link

@jannisg What you ended up using?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants