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: introduce Quick View component #1898

Merged
merged 7 commits into from
Dec 29, 2020
Merged

feat: introduce Quick View component #1898

merged 7 commits into from
Dec 29, 2020

Conversation

EvilAlexei
Copy link
Contributor

Related Issue

No related issue

Description

This PR introduces the Quick View component

Please check whether the PR fulfills the following requirements

  1. The output matches the design specs
  • All values are in rem
  • Text elements follow the truncation rules
  • hover state of the element follow design spec
  • focus state of the element follow design spec
  • active state of the element follow design spec
  • selected state of the element follow design spec
  • selected hover state of the element follow design spec
  • pressed state of the element follow design spec
  • Responsiveness rules - the component has modifier classes for all breakpoints
  • Includes Compact/Cosy/Tablet design
  • RTL support
  1. The code follows fundamental-styles code standards and style
  • only one top level fd-* class is used in the file
  • BEM naming convention is used
  • Mixins are used for repeatable code (fd-rtl, fd-ellipsis, fd-flex, fd-selected, fd-focus, ect.)
  • A11y support - keyboard support, screenreader support, proper ARIA attributes, etc.
  • fd-reset() mixin is applied to all elements
  • Variables are used, if some value is used more than twice.
  • Checked if current components can be reused, instead of having new code.
  1. Testing
  • tested Storybook examples with "CSS Resources" normalize option
  • tested Storybook examples with "CSS Resources" unnormalize option
  • Verified all styles in IE11
  • Updated tests
  1. Documentation
  • Storybook documentation has been created/updated
  • Breaking Changes wiki has been updated in case of breaking changes.

@netlify
Copy link

netlify bot commented Nov 19, 2020

✔️ Deploy preview for fundamental-styles ready!

🔨 Explore the source changes: bb2ac13

🔍 Inspect the deploy logs: https://app.netlify.com/sites/fundamental-styles/deploys/5feb28e0eda0f100079766ae

😎 Browse the preview: https://deploy-preview-1898--fundamental-styles.netlify.app

@InnaAtanasova InnaAtanasova changed the title WIP feat: (quick-view) introduce quick view component [WIP] feat: introduce Quick View component Nov 25, 2020
@InnaAtanasova InnaAtanasova requested a review from a team December 8, 2020 15:28
@EvilAlexei EvilAlexei changed the title [WIP] feat: introduce Quick View component feat: introduce Quick View component Dec 14, 2020
@dimamarksman
Copy link
Contributor

Looks like an extra element:

image

@dimamarksman
Copy link
Contributor

Two nested elements with the same selector:

image

@dimamarksman
Copy link
Contributor

It would be great to add an example in RTL mode

@Lokanathan-k
Copy link
Contributor

HI @EvilAlexei
content are not truncating instead expanding the popover.

Expected:

image

Actual implemented:

image

</div>

<div class="fd-quick-view__group">
<div class="fd-quick-view__group__title">
Copy link
Contributor

Choose a reason for hiding this comment

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

it should be -title instead of __title

@EvilAlexei
Copy link
Contributor Author

EvilAlexei commented Dec 14, 2020

Looks like an extra element:

This element is a content holder inside flex layout, also there is a fix for flex width :)

@dimamarksman
Copy link
Contributor

dimamarksman commented Dec 14, 2020

Looks like an extra element:

This element is a content holder inside flex layout, also there is a fix for flex width :)

If it's just a container to follow a flex layout we should name it properly cause fd-quick-view__text does not describe the purpose it's used for (fd-quick-view__text looks like a common thing for any text element in scope of this component).

@InnaAtanasova
Copy link
Contributor

Hi Oleksii,
from what I see in the specs Quick View is a composite component consisting of Header+Subheader+Content. Header and Subheader are extending the functionality of Bar component and the Content is extending the functionality of Form-Display Mode. This means that this component should contain classes that overwrite the classes of the mentioned components (if needed). For example if the header of the Quick view is different from the Bar header, then you create a modifier class fd-bar fd-bar--header fd-quick-view__header and fd-quick-view__header does not bring the reset. In the specs I didn't see any rule overwritten, which makes me think that this component should go into the "Patterns" category and be built out of already existing components.

@stefanoScalzo
Copy link
Contributor

Screen Shot 2020-12-14 at 11 47 03 AM
z index should be fixed

@EvilAlexei
Copy link
Contributor Author

Looks like an extra element:

This element is a content holder inside flex layout, also there is a fix for flex width :)

If it's just a container to follow a flex layout we should name it properly cause fd-quick-view__text does not describe the purpose it's used for (fd-quick-view__text looks like a common thing for any text element in scope of this component).

It's a name based on semantic content, and it's a common name for such content.
Also, we already have similar class naming in a similar structure, in the card component: https://sap.github.io/fundamental-ngx/#/core/card#standard

In my opinion semantic name better than styling naming. It's higher chances that styles will be changed, but the type of content has fewer chances to be changed.

@stefanoScalzo
Copy link
Contributor

Screen Shot 2020-12-14 at 11 47 55 AM
we should have some type of overflow for the title

@EvilAlexei
Copy link
Contributor Author

EvilAlexei commented Dec 14, 2020

Screen Shot 2020-12-14 at 11 47 55 AM

we should have some type of overflow for the title

It's based on the content used for the title. For example, if we use fd-title
download

@EvilAlexei
Copy link
Contributor Author

Screen Shot 2020-12-14 at 11 47 03 AM
z index should be fixed

This is a popover issue, not related to the quick view styles.

@dimamarksman
Copy link
Contributor

dimamarksman commented Dec 15, 2020

Looks like an extra element:

This element is a content holder inside flex layout, also there is a fix for flex width :)

If it's just a container to follow a flex layout we should name it properly cause fd-quick-view__text does not describe the purpose it's used for (fd-quick-view__text looks like a common thing for any text element in scope of this component).

It's a name based on semantic content, and it's a common name for such content.
Also, we already have similar class naming in a similar structure, in the card component: https://sap.github.io/fundamental-ngx/#/core/card#standard

In my opinion semantic name better than styling naming. It's higher chances that styles will be changed, but the type of content has fewer chances to be changed.

From provided card example the class name is fd-card__header-text that means text area in header scope. But here you use fd-quick-view__text that is more general thing. Let's use fd-quick-view__header-text or something similar to point the scope this text is belong to.

Copy link
Contributor

@JKMarkowski JKMarkowski left a comment

Choose a reason for hiding this comment

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

Hello @EvilAlexei I added some comments, that will drastically change component structure. This should be more composition of components, not standalone component. I can't see any specification for quick view. PM me, if you willl have any questions

src/quick-view.scss Outdated Show resolved Hide resolved
Comment on lines 12 to 22
min-width: 20rem;
max-width: 30rem;
Copy link
Contributor

Choose a reason for hiding this comment

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

Where are those limits from?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't able to find any info about those limits in the design docs,
but this component has already pre-defined content and I think those limits are necessary for the view perception.

For min-width I used a width value from [examples], (https://sapui5.hana.ondemand.com/#/entity/sap.m.QuickView/sample/sap.m.sample.QuickView) They all have 320px width.

I wasn't able to use max-width as well from those examples because it is dynamic there,
so 30rem is my assumption

Copy link
Contributor

Choose a reason for hiding this comment

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

Could you then put it as a hardcoded value into examples? You can use inline-styling or check how it's done with dialog

src/quick-view.scss Outdated Show resolved Hide resolved
src/quick-view.scss Outdated Show resolved Hide resolved
src/quick-view.scss Outdated Show resolved Hide resolved
@JKMarkowski JKMarkowski changed the base branch from master to main December 17, 2020 10:53
Copy link
Contributor

@JKMarkowski JKMarkowski left a comment

Choose a reason for hiding this comment

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

Hello @EvilAlexei Great job with refactoring this component. You are almost there, I added some code related comments

Comment on lines 12 to 22
min-width: 20rem;
max-width: 30rem;
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you then put it as a hardcoded value into examples? You can use inline-styling or check how it's done with dialog

src/quick-view.scss Show resolved Hide resolved
src/quick-view.scss Outdated Show resolved Hide resolved
src/quick-view.scss Show resolved Hide resolved
</div>
`;

RTLMode.storyName = 'RTL mode';
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's also remove RTL mode example, there is a way to control direction on docs header
image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changed

@EvilAlexei
Copy link
Contributor Author

Hello @JKMarkowski, thank you for your comments!

About min-width and max-width, just I think it's better to have these limitations for a better view,
because of pre-defined content and structure.

About min-width:
For example, it's ok for the popover to have no such limitations, It could be used with any sort of content,
but the dialog has pre-defined min-width because you have an assumption about content there.

About max-width:
I see two almost the same ways setting width here, to set a specific width, or to have min/max-width.
With the specific width, a user has to set it all the time.
But with such limitations, it could be more dynamic, and a user still able to set width, but it's not necessary.

@stefanoScalzo
Copy link
Contributor

Screen Shot 2020-12-14 at 11 47 55 AM

we should have some type of overflow for the title

It's based on the content used for the title. For example, if we use fd-title
download

Then maybe we should use fd-title, there should be some type of ellipses standard for text overflow

@EvilAlexei
Copy link
Contributor Author

Screen Shot 2020-12-14 at 11 47 55 AM

we should have some type of overflow for the title

It's based on the content used for the title. For example, if we use fd-title
download

Then maybe we should use fd-title, there should be some type of ellipses standard for text overflow

Yeap, I already used it with fd-title, and fd-link with title needs additional adjustments, I added styles for that, now it should work as requested.

@JKMarkowski
Copy link
Contributor

About min-width and max-width, just I think it's better to have these limitations for a better view,
because of pre-defined content and structure.

About min-width:
For example, it's ok for the popover to have no such limitations, It could be used with any sort of content,
but the dialog has pre-defined min-width because you have an assumption about content there.

About max-width:
I see two almost the same ways setting width here, to set a specific width, or to have min/max-width.
With the specific width, a user has to set it all the time.
But with such limitations, it could be more dynamic, and a user still able to set width, but it's not necessary.

Hello @EvilAlexei, thanks for complex response, I totally agree with you that those limitations will be a little handy for users, but it's same situation as with dialogs, or card. We provide such a limits on docs level, because specification doesn't specify them. Let's keep it same with this component.

Everything else looks great for me. Good job!

Copy link
Contributor

@JKMarkowski JKMarkowski left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@katekozlowska katekozlowska left a comment

Choose a reason for hiding this comment

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

Looks good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants