Prember / Multiple File Support

[evoactivity]

Prember pre-renders routes into a static directory structure with index.html files at build time. I'd like to be able to use the lightning strategy for deployment and pre-render my static routes. This can be supported by grabbing the files from s3 as assets, but you lose the ability to effectively use revisions, uploading the html as assets using the s3 plugin means the index.html files will be overwritten as they are not fingerprinted. I would like to upload all the html into redis just as it stores the main ember index.html file to retain the ability to have revisions.

I've noticed in the past a PR was rejected, as a use case didn't really exist at the time and the suggestion of using the plugin multiple times as part of the pipeline was the correct advice. The past issues and pr were about uploading a single other file. An app may have tens or hundreds of static routes being prerended by prember so creating a plugin entry for each html file would be cumbersome, prone to error and not very scalable.

I'm creating this issue to spark at the least a discussion about if prembers rising popularity changes the conversation around supporting multiple file support and if it should be pursued as part of this plugin.

[lukemelia]

@evoactivity I'm open to the idea if we can come up with a way to do it that doesn't diminish usability for the primary use case for this plugin. Perhaps you can describe your proposed changes in this thread and we can discuss.

[evoactivity]

I think it could be acheived by using the filePattern as a glob and always expecting an array of files with 1 or more entries. Then in the plugin upload method loop over the list of files and upload each to redis. We would need to generate the file identifier for the key based on the file path. So if you have a prember file structure like so

dist/
├─ _empty.html
├─ index.html
├─ about/
│  └─  index.html
├─ privacy-policy/
│  └─  index.html

keys such as keyPrefix:_empty:revisionKey, keyPrefix:index:revisionKey, keyPrefix:about-index:revisionKey, keyPrefix:privacy-policy-index:revisionKey would be generated.

To activate a revision the redisClient.activate method would need to first search redis for all keys matching keyPrefix:*:revisionKey rather than looking for the single keyPrefix:revisionKey and then activate each of them.

This would allow the users server code to translate a route like domain.com/about/ to about-index and use that to return the correct html for that route by concatenating to keyPrefix:about-index:current, if it doesn't exist they can look up keyPrefix:_empty:current and let ember handle the routing client side.

I believe this can be done without breaking or changing current build pipelines. Currently the keyPrefix includes what I'm going to call the page identifier (index by default). To keep this change backwards compatable we could add a check if the keyPrefix passed in by the user includes a separator character (:, /, | etc) then we use the keyPrefix as is for the root index.html but for other files split it at the separator and only use the first part to generate the rest of the keys. That way if someone has their server fetching theirKey:homepage:current this won't break and their build will continue creating a theirKey:homepage entry.

It will be a while before I'm up to deployment on my current project but I can take a look at an initial PR when I get to it.