Improve theme-ability

[james-collapse]

Description

Separate code for CSS, HTML and business logic, in order that new clients wanting to create their own front-end for a PlaceCal site only need to adapt the HTML and theme.

Acceptance criteria

• I can select the theme my site uses in a config file or similar
• I can develop a theme and have all the files in one place
• It's clear from the README how to create a new theme
• Once created, I can continue to get functionality updates without affecting my theme

Plan

• Fork the repo
• Figure out how to "ignore" files when sync-ing with upstream
• Identify the places where we want to encourage customisation and add to the list below
• Figure out a dir structure that makes it most obvious where the "local theme code" lives
• Update the README accordingly
• Next steps: Make a plan for extracting The Trans Dimension as a fork of a template-type repo

Site specific files that are already separate

We can consider moving all of these into a single directory

• src/Copy/Text.elm
• .env
• elm-pages.config.mjs
• Everything in public/ apart from the reset css in style.css
• Everything in content/

Files with site specific code and shared code we need to separate

• We think we can make a Global Layout module with styles to share and a Global Skin module that is specific per site src/Theme/Global.elm
• Extract the text strings for all and the paths for site specific view into Copy/Text.elm - we might also need to cater for sites who's logo is not svg. src/Theme/Logo.elm
• Extract styles for everything in src/Theme/ that we want to be customisable and put into the new Global Skin module. We think we can leave markup and layout rules and replace the cosmetic values with values pulled from Global Skin.

[huly-for-github]

Connected to Huly®: TD-500

[kimadactyl]

Looks great. Have added some suggested AC. I think this is really exciting!

[katjam]

@james-collapse When you start work on this, do you want to have a call to talk through a plan? There are various tensions and choices at stake here so it could be good to make the plan together. @mateusfpleite @kimadactyl welcome to join in too.

My worry is that on one hand - we might be better off starting from scratch depending on the actual use case. In practice themeable/configurable frontends are hard to get right in terms of how much is configurable. We already have a set-up that allows folks make a bespoke site by editing the templates in Theme & the UI copy in Copy/Text. So it depends how far we want the decoupling to go. It's definitely worth doing an audit to see where things could be teased out and where they could remain in place. We could build a system similar to the UI copy one for styles so that some things were centralised and "configurable in plain english" but we should definitely start that with a small set of variable things that do not involve changing layout or content - because that's where bugs and niggles would creep in.

[kimadactyl]

Perhaps the missing context here is that James wants to make a fruit salad site but we think it's a bit premature to develop the features in parallel

I don't think anyone's suggesting making this "cofigurable in plain english" - this is just first steps towards a common featureset with multiple implementations.

Not sure what you mean by starting from scratch in this context - but for me if I was starting again I wouldn't use Elm so I think that's just a totally sep project!

[katjam]

Perhaps the missing context here is that James wants to make a fruit salad site but we think it's a bit premature to develop the features in parallel

Perfect! I was going to suggest we find an org who wanted to "get a themed site" in return for a donation to the GFSC Community so that we were working to a real use case.

It should be relatively straightforward to plan by doing in the sense of extracting to variables everything @james-collapse comes across that wants to be different for Fruit Salad. And let a structure emerge from that. My worry was with the talk of HTML and CSS I thought we were aiming to get vanilla templates to integrate with the elm logic - which in that case I would say definitely rewrite in another tech stack. The advantage of the way it is now means none of the views can be accidentally broken. I think we will be able to get quite a long way towards goal by editing the Global theme styles.

[kimadactyl]

Gotcha. Maybe the AC need a little love. I think you're right a meeting would be nice but I'm also v keen for us not to get in james' way :)

[james-collapse]

@katjam @kimadactyl @mateusfpleite happy to have a meeting about this! I think it’s best we do that before I start, because otherwise I could end up down a rabbit hole.

Monday and Tuesday afternoons, Wednesday mornings and Thursday/Friday evenings are generally best for me.

[katjam]

I could do tomorrow or this Friday evening. Next week chaos for me. Why don't you mail an invite for a 45min slot that works for you and we'll see?

[katjam]

Following the chat with @james-collapse and @mateusfpleite I've changed the title of the issue to make it more in line with our strategy, which I will outline here shortly.

[katjam]

@james-collapse I've made a start of a plan so we can see how we go. I suggest in order to keep this simple, we raise issues incrementally and see how we go! Please feel free to alter the plan. :)

[james-collapse]

This is great, thanks @katjam!