Scully: Add an --extraRoutes option to the CLI

[michielkikkert]

🧩 Feature request

Add an --extraRoutes option to the CLI

Description

I have a pretty sizable site - and often, the only thing that changes is - for example - the price of a single product in the underlying CMS. For that I do not want to re-render all routes, but just a single route.

Be cool to be able to run a single path or a couple of paths from the CLI.

Describe the solution you'd like

Running something like scully --extraRoutes='/route','route2/thing' - and JUST have those 2 routes statically rendered.

Describe alternatives you've considered

I now have to keep making changes to scully config (extraRoutes) to be able to do this. This also ends up in source control etc... which is not ideal.

[aaronfrost]

This already exists. There are two filters that you can use: baseFilter and routeFilter.

The baseFilter filters down to UnhandledRoutes (ie: routes that still have the parameters in them, a la /foo/:fooId).

The routeFilter allows you to use a fuzzy matching syntax to match to the HandledRoutes that you care about (ie: routes that have replaced the parameter with an actual value, a la /foo/123). You can use * as a wild card. So you could use /foo/1*3 to match /foo/103 and /foo/123.

Try them out, and see if they work. If they work, AWESOME. If not, let's chat on the phone and see how we can help.

[michielkikkert]

Right. I spoke about this with Sander. A filter is not necessarily handy as I load all my routes with 'extraRoutes' through a get call to an API in the first place. And those routes do not end up in the Scully routing files (and I like that actually). But this means - I have nothing to filter in the first place ;-)
I admit my case might be niche though... So I can use my work-around if the conclusion is that this is not a handy feature. No probs.

[aaronfrost]

No. I see what you mean. It seems like the routeFilter should filter out the discovered routes as well as the provided extraRoutes. @SanderElias it seems that this should be the default functionality. Since extraRoutes just gets appended to the handled routes, wouldn't we want to filter those as well? I think so. We should do it.

Also, should probably include extraRoutes in the scully-routes.json, maybe. Let's talk about it.

[aaronfrost]

Regardless, here is a blog with lots of good info, including the base filter. https://samvloeberghs.be/posts/scully-and-angular-universal-comparing-benchmarks

[michielkikkert]

Also, should probably include extraRoutes in the scully-routes.json, maybe. Let's talk about it.

I'm not sure if that is a good idea. I think the issue would be that it would always re-render the routes that are found in scully-routes.json right? At least for me - that would be a pain. I'd like my static/dist folder to be as untouched as possible as that is the folder that get's deployed (in a single blob to a worker, I do not have the luxury of being able to deploy single files). So ONLY generating / overwriting files that have been changed would be (for me at least) the ideal scenario.

So at the moment, I have a http call in extraRoutes inside the config. But that is usually commented out now the site is up and running. I now need to just be able to (re)create the deltas.

[SanderElias]

• extra routes are added to the unhandled routes.
• those are then processed by the router plugins
• and end up in the handledRotues
• all handledRoutes end up in the scully.routes.json.

Correct me if I'm wrong, but I think @MikeOne is asking for a way to add extra unhandled routes from the cmd line.
This is the opposite of a filter which by definition skips everything that's not a match.

I think this is a valuable addition, as it makes integration in some systems easier.
It will take some tinkering because this means we need to start updating the scully.routes.json instead of just overwriting it with the last version.

[michielkikkert]

I guess in my scenario at least, I do a full generation run - with all URL's (the ones that are auto-detected from router files - just a handful - plus the ones I'm fetching from an external API in extraRoutes, about 400 of them). AFTER that, I'd only like to (re)generate the changes (unless something functional changed in the Angular app that might affect more routes). This massively lowers the risk that something breaks. So for me, scully.routes.json is pretty much useless anyway - as it only contains the routes that were found (or manually added in extraRoutes) from the most recent Scully run. However, if all routes (ever found?) would end up in scully.routes.json AND these are therefore always picked up as well, I can no longer do my delta-generation - at least not without having to (manually) delete scully.routes.json first. Also not ideal.

I guess what I'm really asking for is an easy way to do just delta updates to dist/static..

[SanderElias]

@MikeOne, Wait, so you want to be able to generate a route, that might not be in scully.routes.json?
For a lot of users, it is important to have a complete list of available routes. For example to drive their menu. or something similar.
(although this might entail that multiple pages need an update when a menu-item changes.)
So, my idea of extraRoutes on the CLI is generating 1 or a couple of routes, and add the missing/updated ones to the scully.routes.json. Updating this file doesn't mean all other pages need to be updated (still, take the caveat I mentioned before in account), so you would still be able to use your delta tool to deploy.

[michielkikkert]

After some more thinking, I came to the realisation that I could simply adapt my workflow to indeed filter instead of 'add'. The way I have this setup now is fine for me at this time, therefore I'll close this feature request.