Skip to content
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

Replace Hogan with Web Components #2751

Open
heyainsleymae opened this issue Oct 29, 2024 · 1 comment
Open

Replace Hogan with Web Components #2751

heyainsleymae opened this issue Oct 29, 2024 · 1 comment

Comments

@heyainsleymae
Copy link
Contributor

Hogan.js, the Mustache compiler used for generating the HTML report, has been marked as unmaintained for almost three years now; changing compilers or templating languages altogether seems to be a prudent move no matter what, and utilising the Web Components standard would remove Hogan as a dependency without the need to replace it with any other external code.

This is obviously a massive undertaking, but I think the reward makes the effort worthwhile. For a start, the existing Hogan templates could be converted to <template> elements fairly quickly, and I've plenty of WebComponent experience from my ProseMirror plugin work. (prosemirror-plugin-outline implements the WAI-ARIA treegrid pattern, and a large chunk of that code could be applied here to improve the accessibility of GoAccess's data tables, addressing part of #2742. I can spin up an example page for that if you'd like, but the relevant web component code is in ProseMirrorOutline.component.js.)

Simplifying the panel creation process would not only speed up HTML report feature development in the long-run, it would also allow those interested in different or more flexible data views—#714, #1079, #2238, #2485, #2642, #2654, #2687, #2731, #2740—to create them independently and with relative ease, either for personal use or as part of a pull request.

Ideally, this new templating approach would mean that a static HTML report—as discussed in #685—could be generated with very large tables, and those tables would be ingested by the custom elements for generating the charts and other dynamic elements.

I'd be able to start investigating this further in a week or two, though I know you are currently working on some of the filtering issues mentioned above, and I don't want to impede that work in any way. Let me know if this is seems interesting, and I can attempt to assuage any nerves by discussing some example approaches in more detail.

@allinurl
Copy link
Owner

I like the idea, it's pretty interesting! Honestly, I'm not too familiar with <template> elements yet, but I agree it's a good time to move away from Hogan if it's not being maintained anymore and we can improve the report this way. Yeah, I'd like to check out that ProseMirror component example you mentioned, if possible.

I'm curious about how much change you anticipate in terms of JS and the templating aspect. I ask mostly because as you have seen, the generated report is self-contained, so I try to keep it as lean as possible. That said, I do prioritize all these improvements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants