AppFrame component

[didoo]

📌 Summary

This PR is a follow-up of https://github.com/hashicorp/ember-shared-components/pull/3 and is the first of the two components ported-back from Cloud UI (and ember-shared-components) to HDS (the other one is #1304).

For details about this decision, see the specific RFC: [DS-047] AppFrame / SideNav - From Cloud UI to HDS

🛠️ Detailed description

In this PR I have:

• ported AppFrame code from the HcAppFrame implementation
  • converted from v2 to v1 addon format
  • I've re-organized the sub-components under the parts folder for simplicity, instead of having siblings
• added a showcase for the AppFrame component (see preview below)
• added the documentation to the Helios website for the AppFrame component (see preview below)
  • I've created a new group called "layouts" for this, that will contain other layout components in the future (eg. "stack/flexbox")

👉 👉 👉 Previews:

• website documentation: https://hds-website-git-app-frame-component-hashicorp.vercel.app/layouts/app-frame
• component showcase: https://hds-showcase-git-app-frame-component-hashicorp.vercel.app/layouts/app-frame

🔗 External links

Jira ticket: https://hashicorp.atlassian.net/browse/HDS-1749
Figma file: this is a layout-only component, no design associated to it

---

👀 Reviewer's checklist:

• +1 Percy if applicable
• Confirm that PR has a changelog update via Changesets if needed

💬 Please consider using conventional comments when reviewing this PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
hds-showcase	✅ Ready (Inspect)	Visit Preview	Apr 13, 2023 2:50pm
hds-website	✅ Ready (Inspect)	Visit Preview	Apr 13, 2023 2:50pm

[meirish]

• converted from v2 to v1 addon format

Just wanted to clarify - strict mode is an existing feature of ember's template layer and is the approved future syntax for templates in ember. V2 refers to a new addon layout that's spec'd here: emberjs/rfcs#507.

[MelSumner]

Curious, why the use of z-index?

One of the things we want to make sure does not happen is that interactive elements could be accidentally hidden behind "sticky" headers or footers.

Some reading:

• WCAG Success Criteria: Focus not obscured
• CSS Technique 43: using CSS margin and scroll-margin to un-obscure content

[didoo]

We're reproducing (with different values) what already happens in production. We need to define a hierarchy of z-index for the top-level content (they will be converted to design tokens in a follow-up task)

[alex-ju]

With the current design/implementation, these z-index values have no effect as all containers have a static position. If one of them changes however (via an override, for example, or a script), having these z-index values can be a good fallback to make sure they overlap as expected.

[didoo]

In any case, there will be a follow-up PR for handling the z-index values in a more systematic way (exposing them as design tokens)

[MelSumner]

FWIW, I think it's a step backward to go to a v1 addon from a v2 addon. I don't really understand why you'd choose to do this when there is a lot of effort being put into getting addons from v1 to v2. Strongly encourage a re-think on this.

[heatherlarsen]

Found a few nitpicky content things, but otherwise, this looks good!

[alex-ju]

Looks good! Don't forget the changelog entry

[alex-ju]

With the current design/implementation, these z-index values have no effect as all containers have a static position. If one of them changes however (via an override, for example, or a script), having these z-index values can be a good fallback to make sure they overlap as expected.