Breaking changes wishlist (for v16 & v17)

[pretzelhammer]

Normally I keep all of these things in my head but I thought I'd make it public and solicit suggestions from other Maker devs & Maker users:

Breaking changes I want to make eventually:

1. remove parentModal from modalApi.state.parentModal. it's already been deprecated, we just need to remove it.
2. change MIcon to take render functions instead of Vue component instances. render functions are more powerful and flexible and it will make MIcon match our other components in API more close, e.g. MDialog, MBlade, MModal
3. refactor the icons object to be more semantic and use more pointers, instead of just @icons.chevronDown and @icons.chevronUp we should have @icons.selectClose = '@icons.chevronDown' and @icons.selectOpen = '@icons.chevronUp' and so on for the rest of the icons
4. rename all instances of critical to error, e.g. @colors.critical, @icons.critical. it's weird that we generally use error and critical interchangeably in the codebase and public api and they're both mean exactly the same thing but a person can never be sure which to use in any particular situation without having to look it up first, which is annoying, so we should just get rid of critical and use error everywhere.
5. change MLoading sizes from normal & large to medium & large to be more consistent with the naming scheme for sizes we use across all other components
6. remove click-handler from MMenuOption and use @click instead
7. instead of allowing null values for iconName in MProgressCircle we should make all undefined & null values illegal, and if people want to toggle the icon we should add a show-icon prop to MProgressCircle similar to how MToast works
8. Mthumbnails should take a CSS validated String for its size prop instead of a Number pixel value
9. move all vue components in /utils to /components and leave the /utils directory purely for js helper functions
10. i want to denullify the default theme, all undefined and null values should be made illegal for all themeable props (and for all props in general). This way merging nested subthemes behaves in a more simple and predictable manner. For example, let's say I have 2 props on a component, called propDoesntAllowNull and propAllowsNull, and let's say this is show they're defined in the root parent theme of the app:

// root parent theme object
makercomponent: {
  propDoesntAllowNull: 'nonNullDefault',
  propAllowsNull: 'nonNullDefault',
},

So far so good, yet what happens when someone passes a subtheme object like this?:

// child subtheme object
makercomponent: {
  propDoesntAllNull: null,
  propAllowsNull: null,
}

The Maker theme resolver can't resolve these 2 props in a consistent uniform way, and trying to do so will break one or the other. For example:

1. The Maker theme resolver assumes null is always a valid value, in which case it will pass null to propAllowsNull BUT it will also pass null to propDoesntAllowNull which will break it
2. The Maker theme resolver assumes null is never a valid value, in which case it will pass 'nonNullDefault' to propAllowsNull and 'nonNullDefault' to propDoesntAllowNull so both will work, but maybe not in the way the developer intended, since it's possible the developer specifically WANTED the default null behavior for propAllowsNull since the prop does allow null as a valid value and yet the theme resolver chose 'nonNullDefault' from the root parent theme instead

I hope it's clear that option 2 is better than option 1, but option 2 doesn't work reliably as long as well allow null or undefined as valid values for themeable props, since it puts the theme resolver in the impossible position of having to read the developer's mind to know if they set null on a nullable prop because they want the null behavior or because they want to go further up the theming chain and inherit a value from the parent theme. TL;DR: we should disallow null and undefined as valid prop values. We can substitute any other arbitrary value if the default null behavior is complex, like the string 'magic' is need be.

Breaking changes I maybe want to make:

• implement v-model for PinInput, remove the complete event and refactor the shakeAndClearInputs method to just shake, or create a new MShake component that PinInput can be wrapped in and remove shakeAndClearInputs entirely. I want to do this because PinInput is the only form component that doesn't have v-model implemented, and the emitted event and public method were only implemented to compensate for the lack of a v-model, but the better solution would have been to just implement v-model.

Breaking changes I wanted to make but turns out I can't:

• removing TransitionResize as I thought it wasn't being used by anyone, but it turns out it's being used by the Checkout team, so it must remain

[pretzelhammer]

All except 2, 3, and 10 are addressed in this PR (v16): #500

We will address 2, 3, and maybe 10 in v17.