Release Notes

Version 0.4

This is a breaking change from version 0.3.x. Some things in Material UI 4.x where breaking changes, but version 0.4 of Muirwik also added several more breaking changes.

For the demo app which is quite large in terms of components used, it took about 10 minutes to make the required changes, and this was not using IDE refactoring support.

Overview of changes

• Added base interfaces inherited from Styled Props that introduces most of the standard html attributes and events and is applied to most controls.

  • Material UI passes on any unused props to parent components and ultimately onto the html element.

  • Before we had things like:

    myControl.attrs.asDynamic().dropzone = true
    myControl.attrs.asDynamic().onMouseMove = { handleMouseMove() }
    myControl.attrs.asDynamic().banana = false
    

  • Now we can do:

    myControl.attrs.dropzone = true
    myControl.attrs.onMouseMove = { handleMouseMove() }
    myControl.attrs.banana = false // Does not compile
    

• Moved to typed props and a system to convert them to the props Material UI expects by using delegates

  • For example,

    interface MMenuProps : MPopoverProps {
        var autoFocus: Boolean
    
        @JsName("MenuListProps")
        var menuListProps: MMenuListProps
    
        @JsName("PopoverClasses")
        var popoverClasses: String
        var value: Any
    }
    var MMenuProps.variant by EnumPropToString(MMenuVariant.values())
    var MMenuProps.onClose by OnClosePropWithReasonDelegate(MenuOnCloseReason.values())
    

    The delegates convert the prop to what Material UI expects, in this case a string enumeration and an event that has the close reason as a string.

    This allows us to use props in a type save way.

    • Before we had things like:

       myControl.attrs.variant = "selectedMenu"
      

    • Now we can do it type safe:

      myControl.attrs.variant = MMenuVariant.selectedMenu
      

• Moved away from huge constructor lists of params. Spent a reasonable amount of time making the props type safe reducing the need for params as mentioned above

  • This makes the code a bit easier to read (I think), and more closely mimics React/Material UI
  • Because of the addition of the standard html attributes and events, making a constructor catering for these introduces large bits of code just copying values from constructor params to prop attributes.

• Moved button components into their own package. This will involve changing your imports (or just getting the IDE to do it for you). If you have hundreds, you may be able to use IDE refactoring to move the buttons to help out

• Changed the signature of lots of controls, probably the most significant is MButton had some of the earlier parameters changed order. Again, if you have hundreds you might be able to get the IDE refactoring to help, but the IDE will show you the problems, and as mentioned, for a reasonable sized app, it did not take too long to change.

• Doing the above basically changed just about every component... so lots of changes and possibility for harm...