Skip to content

Conversation

@hqhhuang
Copy link
Collaborator

Bug/issue #, if applicable: 89970711, 89691884

Summary

With the new Hero/Introduction section design, we are removing the dark hero design from symbol pages. This means that only Articles, Sample Code, API Collections, Top-level technology pages should render the dark Hero background.

This PR also fixes the extra gray divider line that was between the Hero and body content.

Testing

Steps:

  1. Run this branch
  2. Assert that only Articles, Sample Code, API Collections, Top-level technology pages have dark hero design.
    Default-Theme-Specs

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

  • Added tests
  • Ran npm test, and it succeeded
  • Updated documentation if necessary - NA

Remove Hero Image from symbol pages
Fix title color with hero removed and fix extra border
fix tests
fix spacing between hero and body
<div class="doc-topic">
<main class="main" id="main" role="main" tabindex="0">
<DocumentationHero :type="symbolKind || role">
<DocumentationHero :type="symbolKind || role" :enableHero="enableHero">
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a huge deal, but we should consider renaming this to better convey what it does—this flag simply adds/removes the special dark background for the hero as opposed to actually enabling/disabling it.

<DocumentationHero :type="symbolKind || role" :enableHero="enableHero">
<slot name="above-title" />
<Title :eyebrow="roleHeading">{{ title }}</Title>
<Title :eyebrow="roleHeading" :style=heroTitleStyle>{{ title }}</Title>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think manually updating the style attribute is necessary here and probably not preferred. I'm actually a little surprised that the SASS functions you're using would actually work in that manner, but maybe they do.

As an alternative, I would suggest maybe just applying a class to the hero element based on the boolean flag you already have. Then, you can just update the CSS for components like the hero as normal, and they would have rules like so:

.documentation-hero {
  &.enhanced-background {
    --title-color: light-color(fill);
    --border-width: 0;
    /* etc */
  }
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got a little further in the PR, and it seems like you already have a class like this that you can already use to do this :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used this method for styling the Title component, but not sure if I can or should do the same for the border width. See: #10 (comment)

$doc-hero-icon-opacity: 1 !default;
$doc-hero-icon-color: dark-color(fill-secondary) !default;
.documentation-hero-disabled {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like these are mostly duplicated from the documentation-hero class with minor adjustments. Instead of toggling between the documentation-hero and documentation-hero-disabled classes, it might be easier to have the documentation-hero class always there and only add a modifier class for when the special dark background is enabled so you don't have to duplicate as much styling—you only need to override a few small things with the modifier class.

.eyebrow {
@include font-styles(eyebrow-reduced);
color: light-color(fill-gray-tertiary);
color: var(--hero-eyebrow);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor thing but maybe --hero-eyebrow-color would be better indicate what the property is used for?

// Center the content using auto left/right margins
margin-left: auto;
margin-right: auto;
margin-top: 0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this strictly necessary? This mixin may be used in a lot of places where this kind of change would be difficult to test. I wonder if there might be a better way of doing this in a more scoped place where this style was needed (same for the other margin change below)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a bit of digging - it seems like the spacing bug this is meant to fix was only happening when the navigator is turned on. (There's extra spacing between the end of hero section and the gray border)
Screen Shot 2022-03-11 at 2 42 02 AM

So I believe it is necessary to fix it in the mixin that specifically applies to the situation where the navigator is open.
@dobromir-hristov what's your thought on this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: Removed this change from the PR. Will open a separate PR to fix this in the body content style change branch.

Copy link
Owner

@dobromir-hristov dobromir-hristov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Marcus gave you already very good input, I will just add on top of that.

hideSummary: () => getSetting(['features', 'docs', 'summary', 'hide'], false),
enableHero: ({ symbolKind }) => (symbolKind ? (symbolKind === 'module') : true),
heroTitleStyle({ enableHero }) {
return enableHero ? {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally I would suggest we apply such css vars with JS logic, only in cases where we need a dynamic value from the JS env itself.

In this case it might make sense to just toggle a class on/off and apply these in pure the SCSS code.
Also light-color is a scss function, it should not work here.

),
shouldShowLanguageSwitcher: ({ objcPath, swiftPath }) => objcPath && swiftPath,
hideSummary: () => getSetting(['features', 'docs', 'summary', 'hide'], false),
enableHero: ({ symbolKind }) => (symbolKind ? (symbolKind === 'module') : true),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cant verify from a data perspective if this is correct. @mportiz08 wdyt?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is meant for top level technologies page that has a symbol kind (module). Maybe Marcus should confirm if this is the correct logic for displaying dark hero background(enable) for the 4 types of pages we are interested in.

},
borderWidth({ enableHero }) {
return enableHero ? {
'--border-width': '0px',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly dont know if its better to have a class to turn on/off the separator or a css var like this.

Copy link
Collaborator Author

@hqhhuang hqhhuang Mar 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason why I chose to use a CSS var like this is because the border is applied in the primary content component. Whether or not the hero should be "enabled" (or rather have the darker background) is not available in that component. So I would need to pass it in a prop.
I'm also not sure which way is better. Maybe Marcus can comment on this as well?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only change this component needs to make (for removing dark background hero from symbol pages) is this border-width change. Versus in the Documentation Hero component, there is more logic so that adding this boolean prop makes sense.

use modifier
fix title styling
fix test after var name change
remove margin top edit
Copy link
Collaborator

@SamLanier SamLanier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Design looks good!

@mportiz08 mportiz08 merged commit 4e3a9b1 into dobromir-hristov:dhristov/add-sidenav-hero-v2 Mar 11, 2022
dobromir-hristov pushed a commit that referenced this pull request Mar 31, 2022
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.

4 participants