Injection vs. in-page components

[ptagell]

Coming across an issue that I think we need to discuss.

Can we create a list of components that will be injected (and centrally controlled) vs. elements that will be added via local sites.

At the moment, looking at the templates site, I think the following will likely be injected:

• Footer
• Header
• Sitemap

Is that it? All the styles are obviously centrally held, but the example files in these components will need to be the production code that is made available. Perhaps we need a production.slim file for those components that will be rolled into some sort of injection?

My questions:

1. How do we do this code-wise? At the moment, for example, the footer code is in the layout.slim file. Ideally, it could be in the templates components folder (otherwise, why have it?)
2. How do we progressively enhance the pages (e.g. so that we have a default link to "Sitemap" stored locally, that is overridden when JS fires and injects in the global page and slider functionality). The same sort of thing would need to happen in the page footer and, likely, the logo lockup. We need the ability to swap that out globally.

Thoughts?

[neilang]

I would like to raise the question, should header/footer be in the repo at all (beyond documentation)? They're not components that can be used by the user and they will need to be compiled to a standalone JS/CSS package.

[ptagell]

I think that's a good question. Ideally, I'd like to empower the whole community to suggest changes to global elements as well as local ones. This is true open source. Also, I think it's important that the CSS / JS used to power the global nav, footer etc is bundled into the same minified / cdnified codebase to reduce requests.

All that being said, there are several complexities that I think may be difficult to overcome:

1. How do we update the header, footer, fonts, colours, global nav across several versions simultaneously (eg. if we ever wanted to update the fonts used, we'd need to update font files, css (for vertical rhythm etc) and possibly JS - potentially, we'd need to then redeploy core css and js files across several versions of the templates (eg. v1, v2, v3).
2. It's highly likely that we're going to need to modify the content of the footer and global nav quite frequently and we need to keep the ability to do this relatively easily (eg. think about how often we have had to modify injection.js in the current templates repo...at least once every two months).

Open to suggestions. Can we choose several files, very specific components, from the asset tree to be rendered into a seperate injection.js file? Even the structure of Injection.js is less than desirable with all of it's embedded and escaped html - is there a more elegant way to do this?

Happy to meet to discuss this - set something up if you think we need to thrash this out face to face.

[neilang]

Good points. What if we had another directory...

/templates <-- for all things part of the template
/injection <-- for header/footer stuff

Then the release process is that everything in the templates directory is deployed in a versioned manner, where everything in the injections directory is deployed in an clobbering manner.

[ptagell]

Ok, I feel like this has been resolved offline. @neilang is it safe to close this one?

[neilang]

Safe :+1: