Starter code for common patterns

[alykat]

Prompted by a question from @DanielJWood — Might be useful to have a system to archive css/js/partials (and doc markup?) for common project structures or slide types. Examples:

Structures:

• Photo scrollytelling slideshow (full project or component of a larger project)

Slide types:

• Full-screen photo (contain, cover)
• Photo left or right
• Photo side-by-side
• Text-only (variable length)

These can all be mined from past projects, but this might be a cleaner, faster starting point, assuming we keep up with migrating improvements after each project is done.

[thomaswilburn]

One option that we used in Seattle that might be worth considering is having "subtype" templates that are based on the main scaffolding, but have those kinds of partials and client-side code already set up--for example, a template that does scrolling photo presentations (with your slide types), or has Leaflet already configured and ready to go (examples: https://github.com/seattletimes/quiz-template, https://github.com/seattletimes/parallax-template). In NPR terms, this might be similar to having a Look At This base separate from the old App Template with its specific partials and JS code.

You do have to do a little more maintenance to handle which changes are merged back to which template, but they don't usually diverge too much, so you can often get away with a pretty straightforward copy of the tasks folder and some of the partials between the different repos, updating the subtype repos as you go when you create one of those projects.

[alykat]

@thomaswilburn Thanks! Do you think these make sense as completely separate repos (as the Seattle Times templates are), or as forks off the interactive-template repo? (Not sure if that would make migrating interactive-template changes easier, or if it's not a huge deal either way since it's a limited set of things that are likely to change.)

[thomaswilburn]

We did them as separate repos because it was easier to check them out that way (a producer could clone the repo to a new folder in ~/.grunt-init instead of having to clone the repo twice and check out a branch). You want them in different local folders so you can differentiate between them at creation time, e.g. grunt-init quiz vs grunt-init interactive.

I also think it's easier to do a diff/copy between code in separate repos using external tools like Beyond Compare/Kaleidoscope/WinMerge than it is to do it between branches, personally, but if y'all get a real Git prodigy on the team maybe your mileage will differ.

[thomaswilburn]

So I was thinking about this a little more, especially in the context of the way that DG-Next works, and one thing that occurs to me is that the sub-templates could actually merge themselves on top of the regular template--they only need to contain the things that are different. If you look in the template.js that actually makes up the grunt-init instructions, there's a line that copies the folder from the root of the template repo into the destination: https://github.com/nprapps/interactive-template/blob/master/template.js#L19 You could add a second line above this that copies the original interactive template to the project folder, and then copy the sub-template over top of it. (See the scaffolding API docs here: https://gruntjs.com/project-scaffolding) It would involve some digging--either patching the props that you pass into init.filesToCopy() or figuring out what pattern it uses to get them and applying it to the original template root--but probably nothing too difficult.