Configuring headers
All our overlays follow similar patterns yet we duplicate their templates and their classes.
Let's common up with a generic pattern that allows an overlay to easily configure it's header.
The pain of this was evident when implementing https://gerrit.wikimedia.org/r/297636 and the required follow up.
In the construction of Weekipedia various patterns emerged which we could use to simplify our codebase and reduce the JS we ship to users.
This patch proposes a new way to generate headers of overlays that is backwards compatible:
https://gerrit.wikimedia.org/r/315426 Hygiene: Allow a more generalised Overlay header
An overlay would have a headings option that can either be an object or a list of headers. This allows us to programatically construct header(s) without having to create a new Hogan template.
To show the benefit I've made use of the new header format in talk overlays:
https://gerrit.wikimedia.org/r/315428 Talk overlay's should not need so many partials
Constraining how we build overlays has the following benefits:
- All headers have consistent class names and properties (prevents us from class-itis)
- Markup is identical for all headers
- Templates should no longer be needed for headers
- Less code and compile time for Hogan templates (now less of them)
- Standardises an approach for adding multiple headers to an overlay
Dealing with different screens
in the EditorOverlay and CollectionEditorOverlay in Gather we have logic for various screens e.g. edit, preview, save
Despite this there is no easy way to do this without editing the entire template or hacking the partial by using overlay-sub-header elements
Let's talk about how we could do this better and find a better approach
e.g. Overlay.prototype.screens = { header: headerOptions, content: contentOptions, template: template }
(see https://gerrit.wikimedia.org/r/#/c/215368/1)
Related
CleanupOverlay
When working on the page issues instrumentation @Niedzielski pointed out that the CleanupOverlay doesn't really do much - it subclasses Overlay and replaces the content area. It renders a list of what are essentially Issues components. It might be a good candidate to look at when starting this refactor work