1225278 - Add ability to throw gaia-components specific errors.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Components, defect)

Description

[Yura Zenevich [:yzen] (please use "needinfo")]

I would like to be able to throw an error for a component that is not localized or missing accessibility. 

For example, I am looking at gaia-toolbar right now. We have a more button that is present when the screen is too narrow for all the controls. That button is represented as ellipsis at the moment and would need more context in terms of accessibility. For it to be more accessible we would need to add either an aria-label or in terms of Firefox OS - a data-l10n-id to the button. It can be done similarly to the way gaia-header handles action button localization. However, I would like to throw an error in case l10n or a11y is not provided.

I'm hoping gaia-component.errors.ERROR_NAME approach is more consistent that throwing generic ones at random.

Comment 1

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: Github pull request.

Comment 2

[Wilson Page [:wilsonpage]]

Comment on attachment 8688075 [details] [review]
Github pull request.

Can you give an example of what these would be used for and how? If we do bake in some QA style checks, I would prefer to `console.warn()` rather than throw.

Comment 3

[Yura Zenevich [:yzen] (please use "needinfo")]

Yeah, I guess console.warn or .error could work. I'm just not certain people will pay attention to console.

An example of it being used in header for instance:

* if action attribute is specified, we would require l10n-action attribute as well.
* if, in that scenario, it is not present, we would throw or console output the problem

I guess I'm more inclined to throw because it would also be easier to do testing then with console.

Comment 4

[Wilson Page [:wilsonpage]]

(In reply to Yura Zenevich [:yzen] from comment #3)
> Yeah, I guess console.warn or .error could work. I'm just not certain people
> will pay attention to console.
> 
> An example of it being used in header for instance:
> 
> * if action attribute is specified, we would require l10n-action attribute
> as well.
> * if, in that scenario, it is not present, we would throw or console output
> the problem
> 
> I guess I'm more inclined to throw because it would also be easier to do
> testing then with console.

My concern with throwing is, that although it's good for production QA, it adds a barrier to entry for people who just want to prototype something quickly. For this reason I'd rather warn and not throw.

Comment 5

[Yura Zenevich [:yzen] (please use "needinfo")]

(In reply to Wilson Page [:wilsonpage] from comment #4)
> (In reply to Yura Zenevich [:yzen] from comment #3)
> > Yeah, I guess console.warn or .error could work. I'm just not certain people
> > will pay attention to console.
> > 
> > An example of it being used in header for instance:
> > 
> > * if action attribute is specified, we would require l10n-action attribute
> > as well.
> > * if, in that scenario, it is not present, we would throw or console output
> > the problem
> > 
> > I guess I'm more inclined to throw because it would also be easier to do
> > testing then with console.
> 
> My concern with throwing is, that although it's good for production QA, it
> adds a barrier to entry for people who just want to prototype something
> quickly. For this reason I'd rather warn and not throw.

Yeah that's a good point, I'll close this bug in favour of using console.err if there's a problem.