material-blazor / material.blazor Goto Github PK

Review:

1. Both have a hide/show content mechanism that appears not to be applied in a fashion that will affect a render; If indeed the hide/show is not needed then remove same.
2. The methodologies are different, if it turns out that #1 is baseless then they should be aligned.

When a previously empty text field is populated by the browser with cached data, labels fail to float.

a la MatBlazor

Per this screen grab:

Per title, and see top app bar behaviour in the demo.

It was this way before the work I did on MdcSelect

Create PMdcPasswordField
Icon or not?
Toggle visibility or not?

Per title. Run demo in WASM mode and observe failure when clicking button to set the tab.

Once a component has rendered and been intialized with Material Theme JS, Blazor must not render otherwise Blazor and the MT JS conflict with each other. Investigate rolling the pattern of using ShouldRender() as in MdcRadioButton and PMdcRadioButtonGroup across all components. This ha the potential to fix one or two other issues en route.

I have a lurking suspicion that there is a better approach. Just not sure yet what that would be!

The Styles directory is presently published along with the nuget package, getting included in a consuming project which ought only to use <link href="_content/BlazorMdc/css/styles.min.css" rel="stylesheet" />

See https://docs.microsoft.com/en-us/nuget/reference/nuspec#license

Empty PMdcNumericDoubleField input correctly defaults to zero value but loses floating label. This is a Flash of Unstyled Content ("FOUC").

Reference material-components/material-components-web#5851

When a toast is requested from a dialog the visual appearance is under the dialog

The Material Theme icon set in MdcIcons.cs and icons.css seems incomplete - needs review.

Cleanup MdcListItem

Should MdcListItem form the basis for MdcList? And should MdcList ne using MdcListElement?

Also examine PMdcRadioButtonGroup.

Pros/cons/decide/resultant code structure

Shows a flash of unstyled content ("FOUC") when a field that disallows blanks is cleared and then loses focus. The floating label stops floating and superimposes over the selected text.

Some of the aria settings appear to be nonsensical.

Seems not to be used and so is marked as deprecated with [Obsolete]

I've added use of a PMdcDatePicker to my application.

It is wrapped in an identical fashion to what I have with MdcTextField:

@namespace GeneralComponents

<PMdcDatePicker Value="@pDateTimeValue"
                ValueChanged="@pDateTimeValueChanged"
                ValueExpression="@pDateTimeValueExpression"
                Label="@pLabel"
                MinDate="@pEarliestDate"
                MaxDate="@pLatestDate"
                SelectInputStyle="MdcSelectInputStyle.Outlined"
                Style="@pAdditionalStyles" />

When I click the control to select a different date the popup is rather mangled. It's functional but ugly.

Issues to review:

• Remove inline-block from year line
• Slightly enlarge datepicker buttons to allow for wider month names without line breaks (e.g. "Fevereiro" in Portuguese is likely to break the format)
• Review how to space weekdays line and days line
• Work out how to ensure that the menu surface is always large enough even when the viewport is vertically narrow.
• As a stylistic issue, when the year pad is being shown, if the current year is more than 7 lines down (28+ years into the year list), it doesn't show because the year list is scrolled to the top. The list should initialize to a scrolled position showing the current year.

The icon foundry mechanism need the following enhancements and tests:

• MdcTabBar doesn't yet implement anything other than basic material icons. This needs some thought in the setting of icons being passed as an enumerable render fragment.
• Two Tone themed Material Icons require a CSS filter element when set as a white (or probably light) color against a dark background. This has been set for toasts but nothing else. Filled buttons are likely to look wrong.
• Font Awesome has only been tested for its free option and we have no intention to pay for pro just to test BlazorMdc. It is possible that there may be unwanted artefacts when using pro, with a particular eye on the Duotone style.

@key appears to be used in situations where it isn't a contributor

Plus componets are presently prefixed with "Mdcp" such as MdcpDatePicker. The only thing differentiating this from core components is the fourth character, a lower case "p". To better differentiate change the Plus naming convention to "PMdc", eg PMdcDatePicker.

Seems to mark up incorrectly since migration to material theme 6.0.0. Need to reveiw markup in BMdc.TopAppBar.razor.

https://github.com/material-components/material-components-web/blob/master/CHANGELOG.md

If the Items parameter is an IEnumerable resulting from a LINQ query (and therefore lazy enumerated), the default radio button isn't set. This was not a problem before the migration to PMdcRadioButtonGroup.

MdcTextField and MdcTextArea have TextFieldCssClass property that is also used in PMdcCascadingDefaults. Review its need and implementation.

It isn't an MDC control
It may even need to be deprecated

Setting a BMdc.List to dense doesn't mark up correctly. This may be a material theme css issue.

Restrict splats to known values in parameter validation

Checkbox and Radio Button ripples are misaligned when the dialog is first opened. This link is probably the solution.

material-components/material-components-web#5443

Autocomplete fields are supposed to be able to disallow blanks, however this is not working for the first autocomplete on the demo page.

Need to develop a policy for comments and inline documentation and to apply consistently.

1. The first text field in the demo (filled) overwrites the label which doesn't move (MdcTextField issue)

2. The password field is using currentValueRight instead of its own backing store (demo page issue)

JS for scrolling to the current year when opening the year pad is disabled. This is because in addition to scrolling the drop down to the right point as desired, the whole browser window is scrolled to hold the datepicker at the top of the viewport. This is undesired.

See https://github.com/BlazorMdc/BlazorMdc/blob/develop/BlazorMdc/Scripts/scripts.js#L91

Presently an MdcMenu is dismissed when a disabled list item is clicked. This is for review. Was previously not dismissed, but only by way of a complex overlay div blocking mouse clicks. To investigate whether there is a better solution that may also be configurable.

Per the title...

• The choice of the radio button sometimes updates the paragraph shown
• Sliding content does not update the radio button

This is a style question. We want to be consistent throughout BlazorMdc.

Two choices:

• Component.razor with an @code block
• Component.razor & Component.razor.cs

Currently the style is #1 (Except the index page of the demo because you can't use a conditional in @code)

Prior to v1.0.0:

• Review attribute ordering with @attributes="[]", remembering that attributes are given precedence from right to left. This has particular impact when BlazorMdc uses event handlers, e.g. in the numeric input component.
• Ensure that all lifecycle methods call their base method at the start of their code block.
• Document all code per #69
• Review IDisposable implementation, in particular for (i) all overrides in children of ComponentFoundation and (ii) to ensure that all components that require disposal (e.g. of ObjectReference) apply it.

Changing the Value parameter from the app consuming PMdcDatePicker has not effect.

• The debouncer text field doesn't get populated with initial data
• The debounce interval should be added to Cascading Defaults

1. Does it still exist or has it been deprecated. Material.io documentation is confusing/contradictory.
2. If it should remain then it needs a demo page.

These classes seem superflous:

• MdcTypography merely references some mdc classes which are auto completed with intellisense anyway
• MdcColor does the same with some bmdc classes
• MdcIcons just seems unwarranted and is incomplete due to lack of public lists of icons. Font Awesome also add new icons all the time so we should not attempt to keep up with helper constants.

This is poorly applied only for the interaction between numeric inputs and their base text inputs. Needs to be rethought and applied on DRY principles to component bases.

Per title