Skip to content

Conversation

@wpears
Copy link
Member

@wpears wpears commented Apr 4, 2025

The mega-menu has an entire backend up stood up to support editing its contents in Wagtail. However, this isn't really something that happens often enough to justify the extra complication. Moreover, by removing the mega-menu from Wagtail, we create the opportunity for separately deployed applications to include it without a bunch of code duplication + effort.

@wpears
Copy link
Member Author

wpears commented Apr 8, 2025

@csebianlander I've included two approaches herein:

I think it's pretty inarguable that the first approach is easier to edit, that said, the second approach is interesting to me in that it paves the way for a self-contained app, deployed statically and built with any technology that can ingest html, to also use the mega menu. One might imagine this html being distributed via a design-system-like package which both the wagtail website and any other self-contained apps would be consumers of.

Going a step further, one might imagine that this packaging system (say, cfgov-templates) could be authored similiar to approach 1, but then distribute the results of approach 2. That is, instead of the jinja engine running at request time, it runs at build time when producing the package output.

What do you think about this? Obviously this would require a bit more plumbing to set up, but would the authorship/editing experience be worth it? That is, is editing a jinja-like (or possibly json) representation a substantial improvement over editing the raw html? Is editing such a representation on par with the current experience for ease of use?
@anselmbradford curious about your thoughts on the above as well

@csebianlander
Copy link
Contributor

That is, is editing a jinja-like (or possibly json) representation a substantial improvement over editing the raw html? Is editing such a representation on par with the current experience for ease of use?

Personally, I think that yes, the jinja-like/json approach (based on the file you linked) is vastly easier to parse and much less likely to be accidentally broken in the process of editing. It's probably roughly on par with the existing/Wagtail-based approach all things considered.

I hear you re: the advantage of the hardcoded approach but would caution that if we went that way it's far likelier that updating the mega menu in the future requires developer intervention to a degree I'm not comfortable with at this point.

@wpears wpears marked this pull request as ready for review April 9, 2025 18:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants