(Feature request) Improve default Share theme

[zadam]

Describe feature

Current theme looks a bit too plain and could be improved.

Additional Information

No response

[zerebos]

I decided to work on this a bit. I'm using the default Trilium dark theme as the inspiration for the share theme. Here's how it looks so far:

firefox_CUyytXHNNP.mp4

Zadam, is it alright to make changes to the template/html as part of this change? I guess it would technically break B/C but let me know what you think.

Edit: Also would it be alright to make a PR enable user-defined templates from notes for share? I have an implementation that works currently that I've been testing with. It looks something like this (don't judge the code too much it needs cleanup):

 // At top of share/routes.js
const ejs = require("ejs");


// At the end of renderNote in share/routes.js
const opts = {note, header, content, isEmpty, subRoot, assetPath, appPath};

// TODO: Add checks for note type == code and language == ejs
if (note.hasRelation("shareTemplate")) {
    // Get the template note and content
    const templateId = note.getRelation("shareTemplate").value;
    const templateNote = shaca.getNote(templateId);

    // EJS caches the result of this so we don't need to pre-cache
    const includer = (path) => {
        const childNote = templateNote.children.find(n => path === n.title);
        if (!childNote) return null;
        return {template: childNote.getContent()};
    };

    const ejsResult = ejs.render(templateNote.getContent(), opts, {includer});
    res.send(ejsResult);
}
else {
    res.render("share/page", opts);
}

So it would allow users to define custom templates per-page (or for a tree via inheritance) with the same parameters available as the default template, and would allow them to even have include templates via child notes of the user-defined template note.

[meichthys]

@rauenzi This looks great!
I'm really enjoying seeing all the improvements you've been pumping out!

[zerebos]

More than happy to help out @meichthys! I love Trilium so I want to give back to both zadam and the community!

I've also been working on some other things in the background for the community like https://trilium.rocks/ but I don't want to go too far or step on any toes, so I don't want to really announce them until I talk to zadam/see how he feels.

[zerebos]

Since you seemed interested @meichthys, I'll just show this here... I've got a light/dark theme switch working and in my local fork users will be able to choose the default theme with a shareTheme attribute. I should really put all of this in a draft PR so people can see as I go and @zadam can tell me no before I try to implement something drastic 😄

firefox_J9CyluerWv.mp4

Edit: I've also got a proper mobile theme and even plaintext search working!

[zadam]

Both the template and the https://trilium.rocks/ look great!

I think that providing a rich template like that out of the box would be great. But I also think that there should be a very plain one available (similar to what we have now) for easy/deep customization without having to deal with a lot of bloat. In the end I think we might want to offer both, although it's not immediately clear to me in what form should these be switchable.

Regarding the template - so far my thinking was that this shouldn't be necessary - the default template already provides everything needed (note tree, title, content) and all the extra customization can be done with the combination of linked JS and CSS (including inserting new UI elements etc.). It's possible that some very specific things would still need a custom template, but I'd rather steer most of the customization towards the more standard JS/CSS rather than niche EJS and very specific Trilium template contract. But my thinking is not very fixed in this regard and I'm open to counterarguments.

[zerebos]

Thanks! I'm definitely happy with how they came out.

I can understand why you would want to encourage using the share js over using custom templates, because custom templates lock you into an api contract of some kind which is not ideal. And to your point, most things can be done client-side for sure, in fact the https://trilium.rocks/ site was originally doing everything pure client-side.

But, I ran into some limitations of this method. For example, adding things like opengraph/twitter headers via client-side js prevents them from being there on page load so that information is missing from SEO and other indexing or link embedding sites. I also found parsing and modifying the existing DOM to be a bit of a pain, but that's something that can be easily fixed/updated in the default template. The other big problem I ran into is the layout having to reflow and shift as things on the client side finished rendering in, and that changes on everyone's PC. It's not end of the world, but it's definitely worse UX than just having things in-place when the page loads.

I have been thinking about what you said about having two different forms of shares though. One that's more advanced like my example, and one that's more basic like the current share. I like that idea a lot but I would almost want to take it a step further. I of course would be in favor of a custom option, but it might also be interesting to have one step below the "basic" option that does nothing but serve the share js/css to enable those wanting to make a truly client side site making use of the apis and fetchNote and such. Though it may be advantageous for them to have an api to get the note tree via an api since waiting for fetchNote and calculating the tree manually could take some time.

[zadam]

For example, adding things like opengraph/twitter headers via client-side js prevents them from being there on page load so that information is missing from SEO and other indexing or link embedding sites.

Yeah, that's true ... In principle, I'm not against custom templates, it's just that I think that users should be steered to use less heavyweight customization options via CSS / JS and only as a last option there can be custom templates ...

[zerebos]

I definitely agree users should be pushed towards client-side js/css as the primary avenue for customization. And I think that would align with the three tiers I talked about (empty/plain, basic, advanced) leaving custom templates to be for edge cases and "at user's risk" rather than a guranteed api