TL;DR, release editor templates are an absolute mess. It's all warp's fault, but he wants to fix it.
All edit pages
On a small scale this problem exists with the edit page for any entity using artist credits:
- server renders an artist credit, which is a list of one or more ArtistCreditNames (artist + credited name + join phrase).
- client can dynamically add more ArtistCreditNames, these are cloned from the first entry and then cleared. Some protections are in place to prevent the user from removing the last entry.
Tracklist (release editor)
The tracklist page on the release editor has several of these "templates":
- server: An empty track is rendered by the server, including a full artist credit template with details from the release artist. This template is part of the DOM, but hidden with css.
- client: Whenever a new track is rendered this track is cloned and filled in + displayed.
- server: The release editor has hacks to ensure one disc is always rendered server side.
- client: There are protections against removing the last disc, any new disc added will clone the first available disc and clear out it's data.
Recordings (release editor)
The recording page has similar templates:
- server: a "recording_suggestion" macro contains the template to both render recordings suggestions on the server, and to render the client-side template for recording suggestions. The client-side template is hidden with css as usual.
- client: It looks like the template version is only rendered when no other suggestions are rendered, so I expect the client clones the first recording suggestion and removes the template class + removes the "display: none" regardless of whether it was cloned from such a hidden template or not.
- server: The "select_recording" macro also renders both the server side instances of this bit of html and a template for use on the client.
- server: A "disc-template" table is rendered by the server for use by the client -- this is rendered seperately from the disc tables already rendered by the server.
- client: Uses the template version, doesn't need the other server rendered versions.
I see three possible solutions here:
- Standardize on a template language for which both server-side and client-sider render engines are available.
- Use separate server-side and client-side template languages, but standardize on their locations in such a way that a developer making changes to one if them is likely to notice the other and make the necessary changes there as well.
Client side rendering
CON: Greatly limits our choice in which template language to use.
Server side rendering
PRO: We can pick a fast template engine for all server-side rendering (e.g. Xslate).
CON: Whenever the client needs to render something, a roundtrip to the server is necessary. Will also need logic to combine requests so the client can send the data for N tracks and have the server return N rendered versions, one for each track.
Keep templates separate
PRO: We can pick the best template language available on both sides, and no unnecessary roundtrips to the server.
CON: Maintenance nightmare.