Nested fragments for centralized and milo block supporting 404 page

[aishwaryamathuria]

Nested fragments for centralized and milo block supporting 404 page

Requirement -
We are working on the story to create a solution for centralized 404 which can render the new 404 adobe.com page - https://main--milo--adobecom.hlx.page/drafts/mathuria/fragments/404-milo-main
JIRA - https://jira.corp.adobe.com/browse/MWPW-130971

Problem statement -
Currently on Milo we can only render one format of 404 https://milo.adobe.com/404-url
The 404.html in every project has tag set which loads milo 404 template.
The document file is authored without blocks https://milo.adobe.com/404.
Once the page load completes it checks for meta tag, milo loads 404 plain html file (if the template meta tag is set) from content root and loads 404.js and 404.css
The JS and CSS convert https://milo.adobe.com/404 to https://milo.adobe.com/404-url
Since the template load happens after loadLCP we cannot add milo blocks or re-author the 404 file in a different way.

Adobe.com required a solution to -

1. Have milo blocks in 404
2. Have only one 404 page for adobe.com projects

Proposed solution -
We have explored a solution to make the above two requirements possible using nested fragments and wanted some inputs on the same.
The change would need us to

1. In the code repo os the project, modify the 404.html as per following -
   a. Remove the meta tag so that the template 404 js and css does not load.
   b. Add a a href tag in main div containing a fragment link and add a class to main tag so that we can write a css to make this fragment occupy 100% screen width
   <main class='divFor404'> <div> <a href='https://main--milo--adobecom.hlx.page/drafts/mathuria/fragments/404-milo-main'></a> </div> </main>
   c. Author the fragment on 404 html 404-milo-main.docx and add another fragment 404-milo-body.docx inside this document
2. Add a css in milo to make section and content occupy 100% width for main divFor404

When user hits 404 page milo loads the 404 template from en folder https://main--milo--adobecom.hlx.page/drafts/mathuria/fragments/404-milo-main.plain.html. The fragment is rendered that contains another fragment.
Milo loads the nested fragment from corresponding locale root. We can keep the second fragment inside milo/fragment and milo/locale/fragment.
We keep only one main central fragment 404-milo-main and have the centralized 404 body in specific locale folders inside milo project.

Since we have already removed the template and the 404.js does not load it does not clear the already painted 404.
Sharing git diff of required changes https://github.com/adobecom/cc/compare/main...aishwaryamathuria:cc:test404?expand=1

Please share your thoughts and inputs on the above approach?

Adding -
@chrischrischris @auniverseaway @salonijain3 @amitbikram @rgclayton @vhargrave @narcis-radu @dstrong23 @Ruchika4 @seanchoi-dev

[chrischrischris]

I think the best solution would be to add block loading support in 404.js. When it's loaded we can continue to hide the page. In addition to that, we could also add a metadata property that specifies where the 404 file to use is located, something like 404path

[aishwaryamathuria]

Hi @chrischrischris
We can look into the changes to specify 404 path in metadata (like gnav-source and footer-source). We had explored the fragment approach as -

• No extra code to make http calls, locale specific conversion and fallback would need to be added separately as Milo fragment module already handles that use case.
• Can make changes work with some additional CSS and existing fragments functionality.
• The fragments solution also provides customised 404 path through fragments and meta tag. Authors can add any fragment path inside the main fragment added to 404.html - 404-milo-main.docx and its localized equivalent path conversion and fallback would be covered by fragments module.

We will continue forward with the metatag governed 404 handling to identify the 404 path. We are looking into proceeding with the following approach.

1. We will remove the 404 template tag from our 404 html.
2. Allow setting 404-source in meta tag. If a page is not found and 404 scenario occurs, the 404 template will be returned.
3. Before milo loading starts we perform the following processing -
   *** Check 404-source in current domain ***

• If 404-source is set we try to fetch the 404_from_metatag.plain.html from https://<localeRoot_404_from_metatag>.plain.html
• If the Url is found we add that in page else we try to find the en equivalent https://<domain>/<404_from_metatag>.plain.html

*** Check 404-source in current domain milo.adobe.com. This will be our fallback for 404-source ***

• If the 404 source content is not found in current domain we check https://milo.adobe.com/<localeRoot_404_from_metatag>.plain.html
• If the 404 source content is not found in locale milo.adobe.com we check https://milo.adobe.com/<404_from_metatag>.plain.html
  (We can skip this if we are authoring 404 in milo/libs/ as they would be found in the current domain but can have it if we are planning to author in the respective locale folders in milo)

*** Fallback ***

• Check locale content root 404 404.plain.html
• Check en content root 404 404.plain.html

Could you share your thoughts on the above approach?

CC: @salonijain3 @amitbikram @dstrong23

[TsayAdobe]

How about creating your own template?

    <meta name="template" content="my404"/>

Then you implement your own my404.js and my404.css.

[aishwaryamathuria]

@TsayAdobe Templates are currently being executed by milo after the blocks have already been loaded. If we do add a plain html after the page completes we will also have to add the load block handling. Currently we can load the custom url in 404 template if we modify it but the content is not getting processed by milo.
The processing to add the plain html from 404-source which will have milo blocks would need to be done before block loads.
We can add the new processing under a template but it would have to be executed outside loadTemplates before block rendering starts or we can call loadArea within template to render the new content which might create a delay in 404 rendering.

[auniverseaway]

Here you go.

https://github.com/adobecom/milo/compare/central-404?expand=1

Milo
https://central-404--milo--adobecom.hlx.page/this-doesnt-exist
https://central-404--milo--adobecom.hlx.page/de/this-doesnt-exist

CC
https://main--cc--adobecom.hlx.live/this-doesnt-exist?milolibs=central-404
https://main--cc--adobecom.hlx.live/de/this-doesnt-exist?milolibs=central-404

1. Federated (centralized) content.
2. You can make your 404 look like anything you want.
3. Default experience (via College) is still BYO404.

[narcis-radu]

Any reason for using the feds value in your 404 meta content?