KeyboardDatePicker readOnly true race condition - material-ui

KeyboardDatePicker from "#material-ui/pickers": "^3.3.10" exhibits a race condition for the readOnly property. In 3 out of 10 automated cypress.io tests, the following click action made the date picker modal appear even though logging proves that readOnly was set to true:
cy.get('.MuiInputAdornment-root > .MuiButtonBase-root > .MuiIconButton-label > .MuiSvgIcon-root').click();
Since material-ui-pickers is no longer supported, it seems like my only options are:
Redesign my UI such that it renders some other read-only widget instead of rendering a KeyboardDatePicker.
Attempt to fix it by upgrading to mui v5. I haven't investigated how to migrate KeyboardDatePicker but I guess I need to upgrade anyway. Hope it solves the problem.
Does anyone see any other options or have any insight on whether #2 would solve the problem and how?

Related

ion-toggle ionChange get called multiple times in ionic

ion-toggle ionChange get called multiple times in ionic. I have tried using different techniques to solve it but I am not successful.
Code 1:
<ion-toggle
(ionChange)="changeData()"
color="success"
checked="{{data}}"
>
</ion-toggle>
Problem: When I used code 1 then ionChange get called multiple time and it does not show correct state first time.
Code 2:
<ion-toggle
(ionChange)="changeData()"
color="success"
[(ngModel)]="data"
>
</ion-toggle>
Problem: Code 2 causes infinite loop. It calls ionChange infinitly.
If anybody has faced similar issue and/or anybody knows how to tackle it then please let me know. Thanks
Infinite loop or multiple time calling of a method can be occurs if you are changing the the value of boolean in (ionChange)="changeData()" while you are already using [(ngModel)]="data" which is changing boolean value on toggling. So remove any code in your code which is changing data on ionChange.
I was facing similar problem when i was changing the value of boolean on ionChange while i was already using [(ngModel)].
So remove any code similar to code below in changeData() method:
// remove code which is changing state again
data = !data
I solved in the following way, remove the link from ngModel or checked with some variable. To go back to the previous state I map with the viewChild and control it from there.
Online test link
here

Angular ngClass trigger change detection error when binded to ngModel validation

I'm trying to set the color of a label in Angular 2 depending on its email-validation like this:
<input type="email" name="email" [(ngModel)]="email" email #currentEmail="ngModel" [ngClass]="currentEmail.invalid ? 'error' : 'none'">
It works as expected on my page, however in Visual Studio Code I get the following error message:
Error: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'error'. Current value: 'none'.
So my questions are:
Why does this message show up?
Whats the right approach to do this task?
Why does this message show up?
You can find a good explaination of why in this issue
This is not a bug, it's a feature of dev mode working as intended. Calling enableProdMode( ) - when bootstrapping the app prevents the exception from being thrown.
That said, it's being thrown for good reason: In short, after every round of change detection, dev mode immediately performs a second round to verify that no bindings have changed since the end of the first, as this would indicate that changes are being caused by change detection itself.
In your plunk, you have the binding [attr.spinner]=isLoading, and isLoading changes as a result of your call to this.load(), which occurs when ngAfterViewInit is fired, which happens as a part of the initial change detection turn. That in itself isn't problematic though - the problem is that this.load() changes a binding but does not trigger a new round of change detection, which means that this binding will not be updated until some future round of change detection.
Whats the right approach to do this task?
Simply replace [ngClass] with [class]. I don't know why, but when trying to reproduce your issue in a plunker, I found out that [class] does not trigger the error.
Edit : use ng-invalid class
You can also style your element based on the angular class ng-invalid.
See this plunker

Silverstripe display logic for Front-end/Bootstrap forms

Silverstripe Display Logic works perfectly on forms in the CMS but I cannot get it to work on forms in the front end, specifically Bootstrap forms.
It will hide the element but won't display it when logic is applied.
//If the wetsuit dropdown is equal to custom then show the fins numerical field.
DisplayLogicWrapper::create(NumericField::create("Fins","Fins"))->displayIf("Wetsuit")->isEqualTo('Custom')->end(),
I see it just needs display to change from none to block.
Is there a way to do this so that it will keep the state on page reload as well? The drop down value will be saved as a DB entry.
EDIT: This works in the CMS but doesn't work in the front end - Custom is part of the enum values.
DropdownField::create("Wetsuit","Wetsuit")
->setSource(singleton('DiveEquipment')->dbObject('Wetsuit')->enumValues())
->setEmptyString('Select one'),
NumericField::create('Fins','Fins')
->displayIf('Wetsuit')
->isEqualTo('Custom')
->end(),
EDIT2: Working with SilversTripe 3.5, Bootstrap Forms 1.20 and Display Logic 1.0.8
1.0.8 is very outdated though.
I don't think you need the DisplayLogicWrapper for most fields… It's meant for fields like UploadField.
Have you tried this?
NumericField::create('Fins','Fins')
->displayIf('Wetsuit')
->isEqualTo('Custom')
->end(),
Not the issue here, but it's worth noting that a bug exists in Display Logic 1.3 and lower where the custom templates exist in /templates/ not /templates/forms/, causing precedence issues.
If you're experiencing problems with a FieldGroup not rendering the correct template or whatnot. Upgrading to Display Logic 1.4 will resolve this.
You'll need to include jQuery and jQuery Entwine for this to work on the frontend. This is untested but should resolve your issue.
class Page_Controller extends ContentController {
public function init() {
parent::init();
Requirements::javascript(THIRDPARTY_DIR . '/jquery/jquery.js');
Requirements::javascript(THIRDPARTY_DIR . '/jquery-entwine/dist/jquery.entwine-dist.js');
}
}

AngularJS - Wrapping nested <select> in a <div> in a form makes its control not be bind anymore

I'm doing a kind of select2 but with much less functionality and we want the form that is above to know about this Control (so we can use $dirty and $invalid).
But I've noted that if you wrap the select that is in the directive's HTML with a div, the $dirty and $invalid of that control stop working. Any idea why ?
Try it out on this http://plnkr.co/edit/UV425G2SMcqRYeX2N4qw?p=preview, go to the select.html file and turn
<select class='form-control' ng-model='selectedval' ng-attr-name='{{name}}' ng-options='item as item.name for item in options' required><option value=''>-- select --</option></select>
into
<div>
<select class='form-control' ng-model='selectedval' ng-attr-name='{{name}}' ng-options='item as item.name for item in options' required><option value=''>-- select --</option></select>
</div>
Ok I asked this as well in https://github.com/angular/angular.js/issues/6862 and got this answer by #caitp:
So your test case is actually running an old version of angular, which
A) does not support the ng-attr-* directives, and B) has a broken
isolate scope implementation.
This is still broken, but in different ways, using angular 1.2.15. You
have a priority issue with the ng-attr-name directive, regardless of
where the control is, and so it gets added to the form
control with the name you aren't expecting.
The reason this "works" with 1.0.8 and without wrapping it in a div,
is because with replace: true in your directive, we merge the
attributes from the directive's compile node (which does contain
name="...") into the root node of the template, so you're sort of
accidentally taking advantage of a poorly documented behaviour of the
compiler, in that case.
Unfortunately, there isn't really a good way to have dynamic form
control names yet (and this is really the root of the problem you're
having), there are a number of PRs adding support for this, and I've
written a hack to decorate the ngModel controller to make this work
(although it might not work anymore, depending on if the new
$interpolate api landed yet or not), you can see that at
http://plnkr.co/edit/hSMzWC?p=preview
So, Matias has an alternative solution for this, it's not clear which
one is going to land --- but in any case, that's about what your issue
is.
In the future it would be good to ask about these on
http://webchat.freenode.net/?channels=angularjs or
https://groups.google.com/forum/#!forum/angular to get answers to
these kinds of support questions (this is not a bug, per se, although
the "issue" you're seeing might be documented better, so PRs welcome
for clarifying that in the compiler docs).

Requerying MS Access Form Causes Filter Not to Be Applied

Recently, I started noticing odd behavior with one of my continuous forms. It contains text boxes in the header which can be used to filter the list. For some reason, whenever this form is requeried, for example when a record is edited or added in another form, this form reverts to its unfiltered state.
I stepped through the code and played around with some variables in the immediate window. The filter is still there, it just isn't being applied. Setting Me.FilterOn = True does nothing, as it is already true. A work around is easy, I can set Me.Filter = Me.Filter, but I would like to find out what is causing this behavior in the first place.
I have other contiunous forms that work completely fine; requerying them does not do anything to the filter. I'm assuming I changed some setting on the problematic form, but I have no idea what. I compared all the settings between the two forms in the property window and found nothing. Does anyone have any idea what is causing this behavior?
Well I figured out what was wrong. I realized the query that the form was based on was a pass-through query. As soon as I changed it to a normal access query, the problem went away.
Unfortunately I had it as a pass-through query for a reason. Mircosoft Access doesn't like my join. Sometimes it throws me a join not supported error, and other times it just gives me screwed up results... Looks like I'll have to rethink this query.