Theme bug: profiles definitions in nested themes merged incorrectly

[laurenhu]

Bug description

When the MTheme resolveTheme function is merging its theme prop with parent themes, profiles are being merged in index order without regard to their id. This could also result in profiles with unexpected properties as well as defaultProfile being overwritten if a nested <m-theme :theme="defaultTheme()"> is used.

In the following situation:

<m-theme :theme="{ profiles: [{ id: 'profile-one', colors: { background: 'red' } }] }>
	<m-theme :theme="{ profiles: [{ id: 'defaultProfile' }] }"></mtheme>
</m-theme>

this is the data on the inner MTheme:

profiles: [
    {
        id: 'defaultProfile',
        colors:  { background: 'red' },
    }
]

Reproduction

Nest a Mtheme component with theme.profiles definitions inside another Mtheme component with different theme.profiles definitions.

Environment

All

Addressed by

No response

Can you contribute a fix?

• I’m interested in opening a pull request for this issue.

[kirill]

assuming we're matching profiles by their ids, how should they be merged? should they be merged together recursively OR should the latter defined profile completely override the formerly defined profile?

Follow-up question: is there a reason we made profiles into an array with profile definition objects with id fields instead of making it into an object where the keys are the ids and the values are the profile definition objects? i.e.

{ profiles: [
    {id: 'default-profile', colors: { /* whatever */ }},
    {id: 'profile-one', colors: { /* whatever */ }}
]}

vs

{ profiles: {
    'default-profile': { colors: { /* whatever */ }},
    'profile-one': { colors: { /* whatever */ }},
}}

???

[kirill]

notes from our slack huddle:

• we don't need a defaultProfile profile in the default-theme profiles array
• we can merge profile definitions in the array by id (non-breaking)
• we can change the profiles array into a profiles object (breaking)
• no hard deadline