Discussing caveat: "Is starting at / and crawling sufficient?"

[jonathaningram]

"Is starting at / and crawling sufficient? Might there be unreachable sections of your site?"

I think for most well-structured sites this should not be an issue since you can hopefully get to every page that ever existed by just clicking through the web of links...

However, for my use case, I want react-snapshot to render a static page that is not linked from anywhere. The page is a variation of one of my form pages, but it only contains the form, not the site layout (header, footer, etc.). (Unfortunately) I use this by embedding this page in another website in an iframe. This is why it doesn't need to be linked anywhere in the main site (it should not be crawled, but it does need to exist statically).

I know the premise of react-snapshot is to be zero-configuration so I'm not sure that my use case will be supported, but do you have any ideas how this might look?

[geelen]

Yeah I think that's common enough. I'm thinking that "zero configuration" should maybe mean "no configuration beyond command-line args". So you could do

react-snapshot / /form?with=params

Alternatively, we could look for something in package.json but... that feels unnecessary

[jonathaningram]

For this type of configuration, are command line args a bit "ugly" in that usually react-snapshot is called inside a package.json script?

"build": "react-scripts build && react-snapshot / /form?with=params"

Which looks like your pushing knowledge of your routes upstream (i.e. out of src up into package.json).

Maybe there's smarter ways / tricks to avoid putting it straight in package.json - e.g. make a local bin/react-snapshot:

#!/bin/bash
react-snapshot / /form?with=params

And then the package.json script becomes:

"build": "react-scripts build && bin/react-snapshot"

Would you solve it like that, or does it not really bother you putting the cmd line args in package.json?

[geelen]

I don't mind it, but to be honest, a bit of config isn't maybe too bad:

/* package.json */
{
  ...,
  "react-snapshot": [
    "/",
    "/form?with=params"
  ]
}

That way at least each line is nicely tracked by version control...

[jonathaningram]

Yeah that would be nicer, especially with, say, 10 paths.

Not that this affects me, but being hard-coded in package.json means that you can't have extra paths that are unknown at compile time (e.g. extra paths created from an array of products).

Not sure if that's something to consider.

[geelen]

Yeah but those should be found by crawling your product index file, right?

[jonathaningram]

Yep it was a contrived example of a set of paths that might need to be generated at runtime based on other data - I don't actually have that case.

[jonathaningram]

Maybe a more realistic example would be if you had paths like /module1/form, /module2/form, ..., /moduleN/form (say these are forms that you embed for a set of N teaching modules)

If N was unknown at compile time then you couldn't put these paths in package.json. Even if N was known, if it was equal to 100 or 1000, then you'd have a massive package.json that could be solved by the extra path config coming from a JS file using a loop.

Anyway, again, I don't need this for my use case so I don't want to overcomplicate the discussion - it just depends how flexible you'd like this configuration to be.

[geelen]

Sorry for dropping this for a while. I think in the case you describe, it probably makes more sense to make like a index page for all the URLs you can't otherwise reach, call it like __index.html or something. If you put a hidden link on your homepage, or point react-snapshot at it directly in package.json, the crawler will find it and cache all those routes.

I think that's better than having an executable config.