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

Component: ebay-notice #28

Merged
merged 6 commits into from
Mar 8, 2018
Merged

Component: ebay-notice #28

merged 6 commits into from
Mar 8, 2018

Conversation

sharma46bhawana
Copy link
Contributor

@sharma46bhawana sharma46bhawana commented Mar 7, 2018

Description

Contains a new component ebay-notice which constructs page and inline alerts.

Context

  • As the alerts can be page or inline alerts (see ebay/skin) we want to get that as an input for customisation. Default is set to page when no input is provided.

  • For a page alert we have a heading tag in the icon that provides it is ordering with a11y users. To provide that customisation we take the heading-tag as an input for customisation. Default is set to h2 when no input is provided.

  • As the alerts are differentiated into 3 types: confirmation, priority and information, we take the type as an input for the customisation. Default is set to priority when no input is provided.

References

This will complete issue #5

Screenshots

Page notice with type: priority
screen shot 2018-03-06 at 5 39 39 pm

Inline notice with type: confirmation
screen shot 2018-03-08 at 10 24 43 am

@coveralls
Copy link
Collaborator

coveralls commented Mar 7, 2018

Pull Request Test Coverage Report for Build 73

  • 9 of 9 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.4%) to 87.665%

Totals Coverage Status
Change from base Build 66: 0.4%
Covered Lines: 392
Relevant Lines: 434

💛 - Coveralls

package.json Outdated
@@ -43,7 +43,7 @@
"marko-components"
],
"devDependencies": {
"@ebay/skin": "^3.3.0-0",
"@ebay/skin": "^3.4.0-0",
Copy link
Contributor

Choose a reason for hiding this comment

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

You can change this to 3.4.0 now. We have verified it (don't forget to regenerate yarn.lock). Or you can simply rebase and force push my commit from 0.1.0 branch. Up to you. Either way should resolve the conflicts below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

okay I will rebase from 0.1.0

@@ -12,3 +12,5 @@ dist
.browser-refresh
integration/template.marko
integration/browser.json
/.vscode
Copy link
Contributor

Choose a reason for hiding this comment

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

We can let these unrelated changes slip through this time, but team, I'd like us to get into the habit of creating separate PRs for anything unrelated to the main issue at hand. This may seem picky, but imagine if we have to rollback this feature commit (for whatever reason) after it is squashed, we probably wouldn't want to roll back these useful .gitignore updates too, but that's what would happen (and then we'd have to re-commit them again). The upgrade of skin dependency is another example of this. I know I'm being exceptionally picky in this case. Sorry ;-)

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 can create a different PR for this, I am not sure about creating an issue though

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let me just do that

Copy link
Contributor

Choose a reason for hiding this comment

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

No need. Seriously. I was just using this as an example :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

okay :)

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm 100% in agreement with this. I know I just try to get improvements in, but small PRs for minor improvements are actually good, too.

Although, I do know there are times when I don't want to forget! So, I guess we create an issue to track it, @ianmcburnie?

level="page"
aria-label-text="this is a notice">
<p><strong>Error:</strong> Please take another look at the following:
</p>
Copy link
Contributor

Choose a reason for hiding this comment

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

Small suggestion, should be all on the same line:

<p><strong>Error:</strong> Please take another look at the following:</p>

OR, on different lines like paragraph below it.

<p>
    <strong>Error:</strong> Please take another look at the following:
</p>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

same as below

level="inline"
aria-label-text="this is a notice">
<p> Couldn't load all the items, please try again later.
</p>
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment about whitespace here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes that looks ugly, I will fix it

model.type = state.type || defaults.type;
const level = model.level;
const headingTag = (level === 'page') ?
(state.headingTag || constants[level].headingTag) : constants[level].headingTag;
Copy link
Contributor

Choose a reason for hiding this comment

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

MINOR: Maybe We should just reset the state.headingTag beforehand rather than having it with the ||. Like an intermediary const?

const level = state.level || defaults.level;
const type = state.type || defaults.type;
let headingTag = state.headingTag || constants[level].headingTag;

if (level !== 'page') {
    headingTag = constants[level].headingTag;
}

Just an exploration, to make the logic pretty clear for the next developer who will look at the code of this component.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmmm now that I am thinking about it I can do
const headingTag = (level === 'page' && state.headingTag) ? state.headingTag : constants[level].headingTag;

Copy link
Contributor

Choose a reason for hiding this comment

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

That works! Much easier to understand now.

model.renderBody = state.renderBody;
model.class = state.class || '';

return model;
Copy link
Contributor

Choose a reason for hiding this comment

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

Both the other components (menu, listbox) just use an object returned:

    return {
        type: state.type,
        isRadio: state.isRadio,
        isCheckbox: state.isCheckbox,
        isNotCheckable: !state.isRadio && !state.isCheckbox,
        label: state.label,
        expanded: state.expanded,
        menuClass: menuClass,
        buttonClass: buttonClass,
        itemsClass: itemsClass,
        role: !state.fake ? 'menu' : null,
        items: state.items,
        htmlAttributes: state.htmlAttributes
    };

@ianmcburnie @yomed Should we enforce a consistent style for code like this, in the lifecycle methods?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

okay I can make the changes

<${data.mainTag}
w-bind
aria-labelledby="${data.type}-status-${widget.elId()}"
class="${data.level}-notice ${data.level}-notice--${data.type} ${data.class}"
Copy link
Contributor

Choose a reason for hiding this comment

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

To be consistent with the other components, the class creation/management should be moved to index.js in the getTemplateData method.

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 was thinking whether I should keep it in index.js when I sent a PR. Okay I will do it

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For the case of notice I would have to create 3 data classes as all three DOM elements would have different classes according to the input

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe just experiment with how you might add classes. Here are two examples:

Menu
https://github.com/eBay/ebayui-core/blob/master/src/components/ebay-menu/index.js#L84-L96

Listbox (soon to be Select)
https://github.com/eBay/ebayui-core/blob/master/src/components/ebay-listbox/index.js#L48-L50

I'm sure you can come up with something to satisfy creating the classes. Also, remember that you can use arrays which make adding the class names very easy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay I will make the changes, thanks! :)

const processHtmlAttributes = require('../../common/html-attributes');
const template = require('./template.marko');


Copy link
Contributor

Choose a reason for hiding this comment

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

Remove this extra line. 😁

Copy link
Contributor

Choose a reason for hiding this comment

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

As a side note, we may want to enforce this through eslint:
https://eslint.org/docs/rules/no-multiple-empty-lines

Copy link
Contributor

Choose a reason for hiding this comment

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

I would approve of that. 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oops!

@@ -0,0 +1,8 @@
{
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe this file (marko-tag.json) and the marko.json won't work in Marko v4, and that configuration needs to be moved up into the root marko.json of the project, per #15.

Therefore, please move this configuration up into the root ./marko.json.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh I missed it, my bad. Will correct it.

return input;
}
function getTemplateData(state) {
const model = {};
Copy link

Choose a reason for hiding this comment

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

@sharma46bhawana You could also do

const model = Object.assign({}, defaults, state);

and avoid

model.level = state.level || defaults.level;
model.type = state.type || defaults.type;

BTW, the above two lines are repeated twice. Maybe a typo.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

nice!

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 think I don't need model anymore

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, you don't need model any longer.

Copy link
Contributor

@yomed yomed left a comment

Choose a reason for hiding this comment

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

Looks solid overall, just some minor comments.

### `ebay-notice` Usage

```marko
<ebay-notice heading-tag="h3" type="priority" level="page" aria-label-text="this is a notice">
Copy link
Contributor

Choose a reason for hiding this comment

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

(minor) Would "this is a notice" be used in real world usage of this component? If not, maybe we can improve it to approximate practical usage (across all examples that use this text).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, I will change it to @ianmcburnie's suggestion

level: 'page',
type: 'confirmation'
};
function getInitialState(input) {
Copy link
Contributor

Choose a reason for hiding this comment

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

You should be able to remove this function entirely -- the default Marko behavior already returns input.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, I thought that as its in compatibility layer it might still need the getInitialState, if not i will remove it :)

<ebay-notice
type="confirmation"
level="inline"
aria-label-text="this is a notice">
Copy link
Contributor

Choose a reason for hiding this comment

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

Please change all example aria-label-text to one of "Confirmation", "Priority" or "Information".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay will do it.

`level` | String | No | "inline" or "page"
`type` | String | No | "priority", "confirmation" or "information"
`aria-label-text` | String | No | adding description for the notice for a11y users
`heading-tag` | String | No| used in case of "page" level notices to specify the heading tag according to the notice's placement
Copy link
Contributor

Choose a reason for hiding this comment

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

I suggest we use heading-level, with a value of 1 to 6. This actually falls in line nicely with aria-level.

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 actually like that. I will make the changes

@ianmcburnie
Copy link
Contributor

I suggest we rename level to type, and type to status. I am open to other suggestions for these names too.

@seangates
Copy link
Contributor

You should work with @ianmcburnie on the last bit, though.

@seangates
Copy link
Contributor

Oh, and there are now conflicts, it appears.

@sharma46bhawana
Copy link
Contributor Author

@ianmcburnie made the changes to make the names, @yomed made the changes you suggested. Please take a look when you get time

`class` | String | No | custom class
`type` | String | No | "inline" or "page"
`status` | String | No | "priority", "confirmation" or "information"
`aria-level` | String | No | adding description for the notice for a11y users
Copy link
Contributor

Choose a reason for hiding this comment

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

@ianmcburnie Did you intend to have this called aria-level rather than something like aria-text or aria-label-text?

Copy link
Contributor

Choose a reason for hiding this comment

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

No, my intention was not for it to be aria-level. Apologies if I caused confusion. Maybe heading-text? Or icon-aria-label - whatever would be consistent with other components.

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 think aria-text would be a better.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, let's go with aria-text. This text is also used to label the region/section (via aria-labelledby) - so I think this choice is a good all round fit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

### `ebay-notice` Usage

```marko
<ebay-notice heading-level="3" status="priority" type="page" aria-level="Priority">
Copy link
Contributor

Choose a reason for hiding this comment

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

Make sure to update the aria-level reference here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes will do it now

renderBody: input.renderBody,
mainClass: [`${type}-notice`, `${type}-notice--${status}`, input.class],
headingClass: [`${type}-notice__status`],
contentClass: [`${type}-notice__content`]
Copy link
Contributor

Choose a reason for hiding this comment

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

headingClass and contentClass can be regular strings instead of arrays.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

okay makes sense

Copy link
Contributor

@ianmcburnie ianmcburnie left a comment

Choose a reason for hiding this comment

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

Nice job Bhawana!

@ianmcburnie ianmcburnie merged commit 48948ba into 0.1.0 Mar 8, 2018
@ianmcburnie ianmcburnie deleted the 5 branch March 8, 2018 18:55
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