Add support for themes and inheritance

[MoOx]

Here is what I have in mind, inspired by how Wordpress handle themes:

• by default some files are in the core and can be overwritten by themes (this will allow "defaut boilerplate" to be killed in favor of a "default core theme")
• every theme files can be overwritten

We have to think a little bit more about that, so people can easily "add" things, not just overwrite (eg: add/merge webpack config/loaders etc?)

This is just an idea, and must be discussed and enhanced :)

[DavidWells]

I like it. 👍

It would also be a good chance to solidify how 'themes' are made.

For instance, all wordpress themes have a header.php and footer.php file. Then the single blog post template is single.php and the pages are page.php https://codex.wordpress.org/Theme_Development#Template_Files_List

This visual representation is also a handy reference: https://developer.wordpress.org/themes/basics/template-hierarchy/#visual-overview.

Not to say that phenomic would need to support everything under the sun but a "standard" way of doing things would be helpful.

I think wordpress did a lot of things right in how they standardized their theming over the years

[DavidWells]

Just an idea on "standardized template". Interested in thoughts =)

config/ # all build scripts and config files
content/ # all content mapped to routes.js
themes/
    /name-of-theme
        /assets # all static assets associated with theme
            /icons
            /fonts
            /images
        /page-templates # all page layouts (automatically parsed)
            /layout-name-1 # custom layout
            /layout-name-2 # custom layout
                LayoutName2.js # layout component
                LayoutName2.css
                /components
                    /cartComponent # specific component for this layout
            /Contact # custom layout
        /components # global components/fragments
        Footer.js # Global footer
        Header.js # Global header with helmet
        style.css # Global styles and @imports
app.js # Main site entry point
routes.js # Route config
metadata.js # any STATIC data you want here
package.json
plugins/ # plugins used by site

The idea behind the /themes folder would be that you could swap out designs. in /config or metadata.js or package.json you would specify your current theme (if more than one exists in theme folder)

The idea behind the /themes/name-of-theme/page-templates folder would be that it could be automatically parsed by the routes.js file and pages would be available.

If site wants to switch out the theme, they would just need a find/replace to swap out FullWidthTemplate with NewThemePageLayoutName and make sure that new theme will render their custom frontmatter (if any)

// before
---
title: Page Xyz
layout: FullWidthTemplate
---
// after
---
title: Page Xyz
layout: NewThemePageLayoutName
---

The idea behind /plugins is coming from https://twitter.com/threepointone/status/755091652734099456/photo/1 which probably needs another thread =)

[DavidWells]

Any thoughts on this?

Starting to build a new site and wanted to try and head in this direction

[MoOx]

You proposal is ok.
I would adjust it like that but keep in mind that this might end behing a default/recommendation (user should be able to adjust the tree at any point)

node_modules
  /phenomic-theme-*
    /assets ?
    /layouts
    /components (or modules) see #529
      /Header
      /Footer
      /...
  /phenomic-(loader)-plugin-...
content/
src/
  /layouts (should we parse this automatically? need to think about this...)
  /components
  routes.js (optional? should this one have defaults too?)
  app.js (optional, should have a default)
scripts/ (optional, should have a default)
  phenomic.*.js 
webpack.config.js
package.json

[MoOx]

The theme/plugins used will be specified in phenomic config

[DavidWells]

is the idea that /phenomic-theme-*/layouts and src/layouts get merged and are both available for use?

Or is /phenomic-theme-*/layouts/Home the default specified by the config and the src/layouts/Home is an override if the name Home matches?

[MoOx]

We can discuss about that :)
I guess the simple thing to do (and flexible) is to allow easily override by default (eg: src/layouts/Home replace the current theme "Home", but if you want original you can probably do

layout: phenomic-theme-blah-blah/layouts/Home

[DavidWells]

Ok going to push forward on building the site with this kind of outline. We are going to open source it as well.

Let me know if you want to jump on a call to chat about it. I'm curious to see how you see the theming work =)

[MoOx]

I already implemented something similar for my previous static engine. The idea is to have a kind of php include_path and reference to files/layouts etc will look in this order

• local src
• theme
• parent theme?
• default theme (in core?)

Should be really easy to handle via webpack resolve option.

[DavidWells]

@MoOx checkout https://github.com/serverless/site/tree/master/src and let me know what you think.

Getting close to a pretty standard structure that (I think) is easy to approach for folks not used to React / Phenomic

My team at serverless was able to jump in and start making tweaks pretty easily

[MoOx]

@DavidWells Thanks for sharing your architecture. The fun part is that I am currently working on that and I almost have the same tree (probably because we discussed about this):

src/
  app/routes,metadata,store
  components/
  layouts/

I will borrow you some interesting stuff like "pages" and the fact that you add README in every folder. I will also move app/* into src directly.

The IndexComponent is interesting. LayoutContainer is definitely confusing. Currently I am using AppContainer according to #444. What do you think about this name?

[bloodyowl]

big nope for me 😄

[MoOx]

At some point you need to have this thing. Pretty sure it's not that hard to handle. And it's kind of a killer feature we can't miss.

[bloodyowl]

how do you consider themes in a react app where modules are static?

[MoOx]

As discussed yesterday we should at least provides this

• user can have only content and specify a npm module as a theme
• user can override any modules by relying on webpack alias (user land, just need docs)

Inheritance is tricky and not easy to handle.

[MoOx]

We will see that later, not a priority for v1.