New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Splitting frontend / backend #1

Merged
merged 3 commits into from Apr 21, 2017

Conversation

Projects
None yet
2 participants
@marrus-sh
Copy link

marrus-sh commented Apr 21, 2017

@yiskah mentioned to me that yall were looking to split your frontend and backend so here's a recreation of my work on tootsuite#652 to do just that. You can view the documentation I added for a basic overview of how this works; I'll explain the technical side in a little more detail below.


The first commit (3dc0955) does the initial split. I used the environment variables SKINS and FRONTENDS to load the site frontends and skins; you can load multiple, although right now only the first will be used. It should (hopefully) be trivial to extend this implementation by letting users pick their preferred frontend via eg user settings, however.

Using environment variables is necessary to ensure that the skins/frontends are properly precompiled. Skins (static site scripting/styling) and frontends (the web app) are kept separate to relieve frontend developers from having to also style, eg, Masto's about pages or static user profiles. I named the default skin rooty and the default frontend tooty.

Right now if the environment variables aren't specified, rooty and tooty are assumed as defaults. This means that existing Mastodon implementations won't suddenly break when you update and forget to set them yourself. However, I don't advise keeping this functionality in the future, as it should be possible to ship Mastodon servers with no frontend, ie, that are just API endpoints.


In the first commit I just copied the entire stylesheets into both the frontend and skins directory, but in the second (896a779) I did my best to delete parts of the stylesheets which aren't used. I was pretty conservative about this, so I'm like 85% sure that I didn't delete something important, but if you notice some part of the web app suddenly not styled correctly chances are it's because it was erroneously deleted here. On the other hand, I know for a fact there are a bunch of rules, especially in the skins directory, which aren't used for anything anymore, and a comprehensive evaluation of this stuff should probably happen at some point.


The final commit (7c458b0) packages the various assets with the frontends and skins. The most annoying aspect here is the "boop" sound; because Browserify isn't really compatible with the asset pipeline I had to use ERB to assign it to a global variable (window.MASTODON_ASSETS.BOOP) and read it from there. It's not a problem just something to be aware of.


Regarding compatibility: The first thing to note is that I basically reverted the changes made in tootsuite#1368 since this is essentially a more robust solution for the same. This is to say, custom.(s)css isn't precompiled anymore or respected if present, and you should fork rooty or tooty instead.

variables.scss is now used to override theme variables, which have been accordingly prefixed with rooty- or tooty- respectively. It's empty by default, of course.

Right now, only frontends which use React are supported, due to the way /app/views/home/index.html.haml works. I'll submit a patch to allow other kinds of frontends if this gets accepted.

Regarding upstream merges: This breaks compatibility pretty bad, for obvious reasons. Most javascripts are just file renames, so git should be able to follow along; the exception to this is emoji.jsx, which is present in both the skin and the frontend, so IDK how git will decide to handle that one lol. The same goes for a number of the style files. After merging any changes to the upstream frontend you should step in and ensure that changes made in shared files actually go to both places.

The most conservative policy would probably just be to use the ours merge strategy for anything frontend-related and then add important functionality ourselves. But IDK.

@marrus-sh

This comment has been minimized.

Copy link

marrus-sh commented Apr 21, 2017

UPDATE: Regarding custom.scss, the previous description is slightly incorrect; it is still (at present) precompiled, it just isn't currently used.

I wasn't sure if having custom stylesheets supported really made sense when the frontend you were using might change, but that's functionality I can add if it's for some reason desirable. Otherwise, removing the custom.scss precompilation step would probably be best.

@r14c r14c merged commit 8b34f1c into heropunch:master Apr 21, 2017

@marrus-sh marrus-sh deleted the marrus-sh:ce-split-frontend branch Apr 22, 2017

@marrus-sh marrus-sh referenced this pull request Apr 22, 2017

Open

Regarding custom.css #13

1 of 1 task complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment