Angular component Input Date does not accept null

Angular component Input Date does not accept null

Posted by: htn on 9 March 2020, 8:41 pm EST

• 

  htn

  • Post Options:
  • Link
    Copy

  Posted 9 March 2020, 8:41 pm EST

  I have upgraded to the latest version 646 of Wijmo in order to use it with Angular 9 Ivy. However, wj-input-date is broken with null value, even when isRequired is false.

  Example:

  <wj-input-date [value]="null" [isRequired]="false"></wj-input-date>
  

  Runtime error:

  [i]ERROR ** Assertion failed in Wijmo: Date expected. Error
      at assert (http://localhost:4200/vendor.js:62317:10879)
      at asDate (http://localhost:4200/vendor.js:62317:11698)
      at WjInputDate.set [as value] (http://localhost:4200/vendor.js:62159:103412)
      at setInputsForProperty (http://localhost:4200/vendor.js:18986:35)
      at elementPropertyInternal (http://localhost:4200/vendor.js:17801:9)
      at Module.ɵɵproperty (http://localhost:4200/vendor.js:25895:9)
      at AppComponent_Template (http://localhost:4200/main.js:417:65)
      at executeTemplate (http://localhost:4200/vendor.js:17340:9)
      at refreshView (http://localhost:4200/vendor.js:17187:13)
      at refreshComponent (http://localhost:4200/vendor.js:18627:9)
  defaultErrorLogger @ core.js:5871[/i]
  

  I can’t even open a ticket for the support because of javascript error at: https://supportone.componentone.com/newcase

• 

  ashwin.saxena

  

  • Post Options:
  • Link
    Copy

  Posted 10 March 2020, 8:16 pm EST

  Hi Hoang,

  We are really sorry for the inconvenience. There may be an issue with the server of SupportOne but it is fixed now.

  Regarding the InputDate, we have forwarded a bug report to the dev team with internal tracking id 424951. We will update you as soon as the issue is fixed.

  Regards,
  
  Ashwin

• 

  ashwin.saxena

  

  • Post Options:
  • Link
    Copy

  Posted 16 March 2020, 11:51 pm EST

  Hi,

  Before Ivy, the order was specified on the component level, in the @Component decorator’s ‘inputs’ property. This way every Wijmo component had embedded info about the correct initialization order. So even if you wrote:

  <wj-input-date [value]="null" [isRequired]="false" />
  

  , isRequired=false was assigned first, before value=null, and this definition worked correctly.

  With Ivy, the initialization order is the same as the order of the attributes specified on the element, so the definition above stops working: value=null will be assigned before isRequired=false. To bring it to work, you must specify attributes in the correct order yourself:

  <wj-input-date [isRequired]="false" [value]="null" />
  

  ~regards

• 

  htn

  • Post Options:
  • Link
    Copy

  Posted 27 March 2020, 1:21 am EST

  Hi,
  
  Thank you for your reply. It does work.
  
  However, I consider it a workaround: We should not rely on the order, it is very dangerous and not documented anywhere. Moreover, in my case, it breaks the application by stopping the render.
  
  I hope the issue will be fixed soon.

  Regards

• 

  ashwin.saxena

  

  • Post Options:
  • Link
    Copy

  Posted 10 June 2020, 11:08 pm EST

  Hi Hoang,

  I am sorry for the delayed response. It seems this is not an issue of wijmo and instead of angular itself. The initialization order in angular ivy is important. That is why setting isRequired after value throws an error. I could not find anything on this in the documentation so I tested it with a small project. Please refer to the link below:

  https://stackblitz.com/edit/angular-ivy-2xacix

  Observe that how setting a different initialization order affects the output of the component.

  And if we do the same in angular 8 (non-ivy), the initialization order does not matter:

  https://stackblitz.com/edit/angular-oz4dgm

  ~regards

• 

  htn

  • Post Options:
  • Link
    Copy

  Posted 14 June 2020, 6:43 pm EST

  Hi Ashwin,
  
  I understand what you are saying. However, I might be harsh to say that:

  • As an user of the lib: I don’t really care that it’s Ivy that breaks the behavior. The result means the lib is not compatible with Ivy and it could not be used. I can not allow anyone in my team to use the component in the condition of using a specific order of the input. It is too much of a risk that someone would forget about it one day and breaks the application

  • Now, as a developer and a clean coder: I would never allow anyone to write a component with input order constraint. Nobody would figure it out. The component should work with any order. Let’s take your example, the right way to implement the HelloComponent should be:

  
  import { Component, Input } from '@angular/core';
  
  @Component({
    selector: 'hello',
    template: `<h1>Hello {{name}}!</h1>`,
    styles: [`h1 { font-family: Lato; }`]
  })
  export class HelloComponent  {
    @Input() firstName: string;
    @Input() lastName: string;
    get name(): string {
       return `${this.firstName} ${this.lastName}`;
    }
  }
  
  

  That way, you do not care about the order anymore. As uncle Bob told: “temporal couplings are often necessary, but you should not hide the couplings”. In your case here, the temporal couplings are NOT neccessary, but you are adding it, it’s even worse.

• 

  ashwin.saxena

  

  • Post Options:
  • Link
    Copy

  Posted 15 June 2020, 5:52 pm EST

  Hi Hoang,

  We understand your issue and we also think that the order should not depend upon the template. We have discussed this with the developers and they said that its a limitation in ivy which unfortunately they cannot overcome.

  Before ivy, we created our own order on the component side so that the user should not have to remember the order. That is why your issue did not exist in angular 8.

  You will need to contact the angular team in order to resolve this issue.

  We are sorry for the inconvenience caused.

  ~regards