fix(core): meta addTag() adds incorrect attribute

[sabeersulaiman]

Meta::addTag() adds a meta tag with httpEquiv instead of http-equiv when
MetaDefinition contains httpEquiv property.

closes #31525

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.io application / infrastructure changes
• Other... Please describe:

What is the current behavior?

Currently when we use the addTag() or addTags() method with a MetaDefinition containing httpEquiv property a meta tag with an incorrect attribute httpequiv will be added instead of the correct http-equiv attribute.

Issue Number: #31525

What is the new behavior?

The changes will add meta tags with the correct attribute.

Does this PR introduce a breaking change?

• Yes
• No

Other information

Creating this PR instead of an old one that I messed up while fixing a conflict: #31542

[lazarljubenovic]

I'm not sure if this is a good approach. We should either transform all camelCase to dash-case, or have an easy-to-edit map somewhere, such as map = {httpEquiv: 'http-equiv' }. This code will turn into mess. Or, the user should simply be in charge of properly passing {'http-equiv': ...} if that's what he wants to add to the tag?

[sabeersulaiman]

@lazarljubenovic agreed, I was expecting something similar to a map before looking into this implementation. But turned out that was not the approach, if users should be held incharge then I think we should drop httpEquiv from the model and have docs pointing to the same

[sabeersulaiman]

But removing httpEquiv can be considered as a breaking change ?

[lazarljubenovic]

Hmm, I guess that would be a breaking change indeed, since it would change this part of the public API:

angular/packages/platform-browser/src/browser/meta.ts

Lines 17 to 27 in bfa0109

	export type MetaDefinition = {
	charset?: string; content?: string; httpEquiv?: string; id?: string; itemprop?: string;
	name?: string;
	property?: string;
	scheme?: string;
	url?: string;
	} &
	{
	// TODO(IgorMinar): this type looks wrong
	[prop: string]: string;
	};

But currently it misleads the developer by suggesting httpEquiv, which will give a wrong attribute (as you pointed out in #31525).

So, in my opinion, the proper solution to the bug (while avoiding breaking changes) is to introduce a mapping object where it will be easy to later edit keys and add new ones, such as this one.

const META_KEYS_MAP = {
  httpEquiv: 'http-equiv',
}

Then if the attribute's key is not present in the map, assume that the key of MetaDefinition object should be taken as the attribute key.

And since this...

angular/packages/platform-browser/src/browser/meta.ts

Lines 24 to 27 in bfa0109

	{
	// TODO(IgorMinar): this type looks wrong
	[prop: string]: string;
	};

...exists, the developer can always add custom attributes by specifying the dash himself.

[sabeersulaiman]

@lazarljubenovic I am gonna go with the approach you suggested as it is cleaner and does not introduce a breaking change.

[mhevery]

presubmit

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}