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

feat(cloud-masthead): add Cloud-specific container and composite components #5593

Merged

Conversation

huntermacd
Copy link
Contributor

@huntermacd huntermacd commented Mar 24, 2021

Related Ticket(s)

https://jsw.ibm.com/browse/HC-1681

Description

This diff adds various Cloud-specific versions of existing components. This should be kept as a draft since there is a lot more work to do, but I need some eyes from the team on the work so far for guidance.

Changelog

New

  • cloud-masthead-container component
  • cloud-masthead-composite component
  • cloud-masthead-profile component

Changed

  • add Storybook story for Cloud variant masthead
  • added selector to masthead.scss to include Cloud-specific masthead

@huntermacd huntermacd changed the title Cloud masthead variant feat(cloud-masthead): add Cloud-specific container and composite components Mar 24, 2021
@ibmdotcom-bot
Copy link
Contributor

ibmdotcom-bot commented Mar 24, 2021

@ibmdotcom-bot
Copy link
Contributor

ibmdotcom-bot commented Mar 24, 2021

@ibmdotcom-bot
Copy link
Contributor

ibmdotcom-bot commented Mar 24, 2021

?has-profile="${hasProfile}"
?has-search="${hasSearch}"
.unauthenticatedProfileItems="${ifNonNull(unauthenticatedProfileItems)}"
data-endpoint="/common/carbon-for-ibm-dotcom/translations/cloud-masthead"
Copy link
Member

@annawen1 annawen1 Mar 24, 2021

Choose a reason for hiding this comment

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

was double checking why the endpoint was resulting in a 404 - turns out I forgot we need to add /jsononly to the path. We should be able to get the data using /common/carbon-for-ibm-dotcom/translations/cloud-masthead/jsononly

Copy link
Contributor

Choose a reason for hiding this comment

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

@annawen1 This is good to know. Thanks for pointing this out. Also, since we're using the JSON-only directory, I'm guessing we don't need the .js within the dotcom translation repo? https://github.ibm.com/webstandards/ibm-dotcom-translations/blob/master/translations/cloud-masthead/usen.js

Copy link
Contributor

Choose a reason for hiding this comment

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

I just wanted to bring this up as this will play in our translation content population workflow and if we're only using the JSON files that would help come down in the formatting of the .js versions. Let me know what you think.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah we don't need the .js file for the translations, I think we initially kept it for consistency when copying over the current ibm.com translations folder structure? Not sure if removing it will cause any issues. @jeffchew what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

@annawen1 Thanks! @jeffchew Let me know if we need to account for the .js files within the Cloud Masthead translation directory.

${profileItems?.map(
({ title, url }) =>
html`
<dds-masthead-profile-item href="${ifNonNull(url)}">${title}</dds-masthead-profile-item>
Copy link
Contributor

Choose a reason for hiding this comment

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

As part of the new Cloud masthead work, we need to expose a CTA button component that links out to the console. This is a new feature that we'll need to account for within the authenticated state of the dds-cloud-masthead-profile component (see specs - https://ibm.ent.box.com/file/786859527229).

component--cloud-masthead-l0--design-specs--1_0_0_pdf___Powered_by_Box

As for the data/translation, we'll need to add this to our JSON file as well. @annawen1 @jeffchew Let me know if there are fields within the existing data structure that we can reuse or if this is something new that we need to add. https://1.www.s81c.com/common/carbon-for-ibm-dotcom/translations/cloud-masthead/jsononly/usen.json

Copy link
Member

@annawen1 annawen1 Mar 25, 2021

Choose a reason for hiding this comment

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

hmm don't see any existing fields we can utilize for the console button so I think we need to add it. Possibly in

"masthead": {
    "search": {
      "btnSearchClosed": "Open IBM search field",
      "btnSearchOpen": "Search all of IBM",
      "btnClose": "Close IBM search field",
      "placeHolderText": "Search all of IBM"
    },
    --> "not sure key name bc I'm not good with naming": "Console"

Copy link
Contributor

Choose a reason for hiding this comment

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

@annawen1 Looking at the existing structure, I think it might be good to add this button within the [profileMenu][signedin] array, as this button is intended to show up in the authenticated state (see attached ). This will be managed outside of the [profileMenu][signedin][links], which is being used to display the user drop-down menu. Let me know what you think.

https___1_www_s81c_com_common_carbon-for-ibm-dotcom_translations_cloud-masthead_jsononly_usen_json

@huntermacd let me know what you think as well.

Copy link
Member

Choose a reason for hiding this comment

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

yep, that looks good! Just note we need to edit the type files in the services store package! Let me know if you need help with that.

Copy link
Contributor

Choose a reason for hiding this comment

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

@annawen1 Great! I'll work on opening a PR to add this new ctaButton array. As for accounting for these types in the services store package, perhaps this is something you can help us add once the data is in place?

Copy link
Member

Choose a reason for hiding this comment

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

sure!

Copy link
Contributor

Choose a reason for hiding this comment

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

Here's the PR to adjust the data structure based on our conversation here - https://github.ibm.com/webstandards/ibm-dotcom-translations/pull/295.

Copy link
Contributor

@proeung proeung left a comment

Choose a reason for hiding this comment

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

@huntermacd Overall, this is a great first draft of the work, and thanks for putting this PR together. @annawen1 and I left some feedback. Let me if you have any questions/concerns.

Copy link
Contributor

@asudoh asudoh left a comment

Choose a reason for hiding this comment

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

Thanks @huntermacd!

@jeffchew Just double-checking; Looks that we are maintaining these components even though it's cloud-BU-specific. Is it correct? Just wanted to see if we decided that PAL route didn't make sense.

@huntermacd
Copy link
Contributor Author

huntermacd commented Mar 30, 2021

cc @annawen1 @asudoh @jeffchew

I could use some assistance wrapping these components behind a feature flag, being that they're interconnected. My latest commit 70085a3 shows my progress on doing that. Currently it's broken. I may have a circular import happening.

Also, regarding the cookie check, this needs to happen on each load of the component. I'm not certain that there's a need to put this value into the store. The goal is to check the cookie for determining which version of the Cloud Masthead Profile to show, either "authenticated" or "anonymous". Putting this functionality into an importable service, a la the ProfileAPI, also seems like overkill when it boils down to a single, simple function. Please let me know your thoughts on the matter.

@annawen1
Copy link
Member

cc @annawen1 @asudoh @jeffchew

I could use some assistance wrapping these components behind a feature flag, being that they're interconnected. My latest commit 70085a3 shows my progress on doing that. Currently it's broken. I may have a circular import happening.

Also, regarding the cookie check, this needs to happen on each load of the component. I'm not certain that there's a need to put this value into the store. The goal is to check the cookie for determining which version of the Cloud Masthead Profile to show, either "authenticated" or "anonymous". Putting this functionality into an importable service, a la the ProfileAPI, also seems like overkill when it boils down to a single, simple function. Please let me know your thoughts on the matter.

@asudoh wonder what your thoughts are on where the cookie fetching logic lives?

@asudoh
Copy link
Contributor

asudoh commented Mar 31, 2021

@annawen1 Thank you for asking. If the team thinks maintaining the login status in @carbon/ibmdotcom-services-store, they can manually change userStatus property in <dds-masthead-composite> or one in <dds-masthead-container>. In other words, cookie handling code should not be baked in to <dds-masthead-*>.

@annawen1
Copy link
Member

@annawen1 Thank you for asking. If the team thinks maintaining the login status in @carbon/ibmdotcom-services-store, they can manually change userStatus property in <dds-masthead-composite> or one in <dds-masthead-container>. In other words, cookie handling code should not be baked in to <dds-masthead-*>.

Thanks @asudoh! @huntermacd, based on Akira's comment I think it may be good to fetch the cookie data within dds-cloud-masthead-container and set cookie value to userStatus. This way we won't have to put the logic in the services-store package and we won't be baking it into dds-masthead-* components

@huntermacd huntermacd marked this pull request as ready for review April 1, 2021 13:15
@huntermacd huntermacd requested review from asudoh and annawen1 April 1, 2021 13:15
@annawen1 annawen1 added feature flag package: web components Work necessary for the IBM.com Library web components package labels Apr 1, 2021
@ibmdotcom-bot
Copy link
Contributor

ibmdotcom-bot commented Apr 2, 2021

Copy link
Contributor

@proeung proeung left a comment

Choose a reason for hiding this comment

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

@huntermacd Looks great! I'm now able to see the CTA button for the anonymous and authenticated states!

@annawen1 @jeffchew I think this PR is good to merge down to the main branch and available for view via the experimental environment. What do you both think?

@annawen1
Copy link
Member

annawen1 commented Apr 8, 2021

@huntermacd looks good! 🎉

One thing - I do see it's failing on one of the tests, can you take a look?
Screen Shot 2021-04-08 at 5 34 38 PM

@huntermacd huntermacd force-pushed the cloud-masthead-variant branch from 494a7ed to d9bdcf0 Compare April 9, 2021 16:45
@proeung
Copy link
Contributor

proeung commented Apr 9, 2021

Looks like all of the CI checks are cleared! @annawen1 Are we good to merge this PR down?

@annawen1
Copy link
Member

annawen1 commented Apr 9, 2021

Looks like all of the CI checks are cleared! @annawen1 Are we good to merge this PR down?

Everything looks good, one thing though sorry! @jeffchew you mentioned about the js-cookie dependency and if it would make more sense to have the cookie fetching logic as part of the utilities package where we already have js-cookie?

We have a similar util called ipcInfoCookie.js there.

@jeffchew
Copy link
Member

jeffchew commented Apr 9, 2021

Looks like all of the CI checks are cleared! @annawen1 Are we good to merge this PR down?

Everything looks good, one thing though sorry! @jeffchew you mentioned about the js-cookie dependency and if it would make more sense to have the cookie fetching logic as part of the utilities package where we already have js-cookie?

We have a similar util called ipcInfoCookie.js there.

That's right, and sorry that I'm catching up with this PR now. What caught my attention was the js-cookie dependency getting added to web-components, where we have separated out the cookie setting and fetching logic (to @annawen1 's point) in our utilities package. It may be nice to also have it there so that the handling of that is centralized.

@asudoh to your question about PAL specific things, I agree that that would be the ultimate goal. This is a first iteration of the Cloud masthead which is why we have suggested putting behind a feature flag. At least the way I'm thinking of, it would be nice to be able to ultimately abstract some of the things happening in this variation of the Masthead so that other teams/BUs can ultimately take advantage of some of the things here, and Cloud would also ultimately be using this abstracted version for their needs too. But for now it can be safely iterated behind the flag while also getting something that can hit the glass for the Cloud team.

@proeung
Copy link
Contributor

proeung commented Apr 9, 2021

@jeffchew Thanks for the response! Sounds to me like we have a good direction on how to manage the cookie settings and fetching logic within the existing @carbon/ibmdotcom-utilities package for future implementation. In the meantime, I think we can proceed with the feature flag and account for the abstraction at a later time. Let me know if you'd like me to create a GH issue for this feature.

Copy link
Member

@jeffchew jeffchew left a comment

Choose a reason for hiding this comment

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

@proeung yes, would typically agree that if we're behind a feature flag, we can safely continue to iterate behind it. However, I think the added dependency in the package itself, regardless if the intention is to move to another package later on, is something we should try to avoid.

I think if at minimum we can move the cookie library dependency out of the web-components package, I think that can be safe to then merge this in.

@shixiedesign shixiedesign added the Needs design approval PRs on feature requests and new components have to get design approval before merge. label Apr 12, 2021
@proeung
Copy link
Contributor

proeung commented Apr 12, 2021

@jeffchew Sounds good! I'll create a ticket for us to track the work for moving the js-cookie dependency and the fetching logic to the existing @carbon/ibmdotcom-utilities package. In the meantime, I think this recent commit (33cf590) that @huntermacd made should allow this PR to move forward with merging.

@shixiedesign I don't believe this PR requires a design QA at the moment. We're working on getting the baseline changes for the new Cloud masthead merged down so that we can add in the other design enchantments. Also, the changes in this PR are behind a feature flag. We'll conduct a proper design QA review once we have all of the elements assembled that you, Lila Title, and others can take a look at.

@huntermacd
Copy link
Contributor Author

huntermacd commented Apr 12, 2021

With the removal of the js-cookie dependency in the web components package, we're getting an import/no-extraneous-dependencies eslint error which is causing CI to fail. I'm not terribly familiar with Lerna or Yarn's workspaces feature, but I'm assuming we're setup to share dependencies in exactly this way. Questions: am I correct in that assumption? And if so, what's the preferred method for getting around this eslint error in cases like this? @jeffchew

@annawen1
Copy link
Member

Pushed changes to move the cookie fetching logic in the utilities package!

@proeung
Copy link
Contributor

proeung commented Apr 12, 2021

@annawen1 Awesome job moving the js-cookie fetching logic into the @carbon/ibmdotcom-utilities package! You've saved us a lot of time with creating the ticket and implementing this work, so thank you so much! 🥇

@jeffchew With the latest commit (864d893) that @annawen1 pushed up, I think we're good for another code review and I think we can safely merge this PR down. What do you think?

Copy link
Member

@annawen1 annawen1 left a comment

Choose a reason for hiding this comment

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

LGTM!

@annawen1 annawen1 added Ready to merge Label for the pull requests that are ready to merge and removed Needs design approval PRs on feature requests and new components have to get design approval before merge. labels Apr 12, 2021
@kodiakhq kodiakhq bot merged commit ae52b30 into carbon-design-system:master Apr 12, 2021
iwhitcomb pushed a commit to iwhitcomb/carbon-for-ibm-dotcom that referenced this pull request Apr 13, 2021
…m into feat/5305

* 'feat/5305' of github.com:iwhitcomb/carbon-for-ibm-dotcom:
  chore(carbon): upgrade to Carbon v10.31.0 (carbon-design-system#5760)
  feat(cloud-masthead): add Cloud-specific container and composite components (carbon-design-system#5593)
  fix(dotcom-shell): add scroll eventListener (carbon-design-system#5747)
  fix(card-pictogram): fixed visual bugs & storybook refinements (carbon-design-system#5736)
@huntermacd huntermacd deleted the cloud-masthead-variant branch April 15, 2021 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature flag package: web components Work necessary for the IBM.com Library web components package Ready to merge Label for the pull requests that are ready to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants