Currency of NumericTextBox is overridden when calling setCurrencyCode()

[Grant]

I have a UI which is able to take input for multiple international currencies. so, I have multiple NumericTextBox controls on a page, each with a different value set for the 'currency' property.

If I call the global 'setCurrencyCode()' method from @syncfusion/ej2-base - all of the controls are updated to this currency.

I believe there's an assumption that the NumericTextBox.currency property is in alignment with the UI currency. I feel that the NumericTextBox should display the UI currency... unless its currency has been set.

I do see that there is an undocumented 'currencyCode' property of the NumericTextBox - but setting that also has no effect in fixing the issue

[Christopher Issac Sunder K]

Hi Grant, 

Greetings from Syncfusion!!! 

We have validated the reported query and we would like to inform that, if you called the setCurrencyCode() method on initial time and currency API is set to the component, based on the priority currency API value will be assigned to the component. If currency API is not provided to the component, then given currency code in the setCurrencyCode() method will be reflected to the component. If you called the setCurrencyCode() method after control rendering, currency code will be reflected to all the EJ2 components defined in the page with specified currency code. So, we suggest you to use setCurrencyCode() method if you want to render all the EJ2 components in the page with same currency code. Else, if you want to assign different currency code, you can use our public API called “currency” as like in the below API link. 

API link: https://ej2.syncfusion.com/documentation/api/numerictextbox#currency 

Please refer the below UG documentation link to know more about currency code. 

UG Link: https://ej2.syncfusion.com/documentation/common/internationalization/?no-cache=1#changing-global-culture-and-currency-code 

Please let us know if you need any further assistance. 

Thanks, 

Christo 

[Grant]

I'm not sure you've understood my issue (or if you feel that it is functioning as expected... which I think is wrong).

Please find attached a small demo app which highlights the issue.

• Extract the files in the attached zip to a new folder
• From that new folder:
• Run 'npm install'
• Run 'npm start'

the code for the UI can be found in `/src/components/app-root/app-root.tsx`

Attachment: currencycodeissue_bf1a3e28.zip

[Christopher Issac Sunder K]

Hi Grant, 

Thanks for the attachment. We have check with the attachment and here is the detailed explanation about setCurrencyCode method, 

The setCurrencyCode method can be used only for setting/ changing the global currency for all EJ2 components in the application.  Please find the behavior of the setCurrencyCode in our components in below:  

  

1.Used ‘setCurrencyCode’ before component rendered.  

  

If the setCurrencyCode method is called before the component render then the global currency(ex: EUR) code will be set for components that doesn’t have set the currency property set.   

// set currency code before component render.  

setCurrenyCode(‘EUR’); 

// currency code not set component wise.  

 

let textbox1 = new NumericTextBox({ 

    value: 2345.67, 

    format: 'c2', 

}, this.el.querySelector('#noCurrency') as HTMLInputElement); 

/// default currency code set.  

let textbox2 = new NumericTextBox({ 

    value: 2345.67, 

    format: 'c2', 

    currency: 'AUD', 

}, this.el.querySelector('#audCurrency') as HTMLInputElement);  

  

 In the above code example, when we set currency code ‘EUR’ before component render the two instances will have different currency values. In the ‘textbox1’  the value will be displayed in the ‘EUR’ and for the ‘textbox2’ value will be displayed in ‘AUD’.  

  

2. Used ‘setCurrencyCode’ after component rendered.  

   

If the setCurrencyCode method is called after the component render then the global currency(ex: EUR) code will be changed to all the components in the page.   

// currency code not set component wise.  

let textbox1 = new NumericTextBox({ 

    value: 2345.67, 

    format: 'c2', 

}, this.el.querySelector('#noCurrency') as HTMLInputElement); 

/// default currency code set.  

let textbox2 = new NumericTextBox({ 

    value: 2345.67, 

    format: 'c2', 

    currency: 'AUD', 

}, this.el.querySelector('#audCurrency') as HTMLInputElement); 

 

// set currency code after component render.  

setCurrenyCode(‘EUR’);  

   

In the above code example when we set currency code ‘EUR’  sets after the component render the two instances ‘textbox1’ and  `textbox2`   will have same currency values `EUR`.  Above mentioned are the behavior of the setCurrencyCode method and if we need to maintain separate currency codes for each component, do not use the setCurrencyCode after component rendered.  

Please let us know if you have any concerns. 

Thanks,
Christo 

[Grant]

Although I think this functionality is somewhat counter-intuitive - I appreciate that it's just a difference of opinion on how it might work.

Might I suggest an update to the NumericTextBox documentation to note that setting the 'currency' will be overridden if setCurrecyCode() is called subsequent to render?

I suppose there's not many instances where the UI currency actually changes - mine is a unique case! 

If anyone else faces this issue: I have a workaround in that I have a service which manages currency and locale changes, and when it calls setCurrencyCode, it also emits an event which can be intercepted. In my components, I listen for the event and then I re-update the instance currency properties to what they were. It feels a little hacky, but it works.

[Christopher Issac Sunder K]

Hi Grant,  

Thanks for the suggestion. 

We will include the needed information in the below documentation page as per your suggestion, 

https://ej2.syncfusion.com/documentation/common/internationalization/#setting-currency-code 

The documentation changes will be refreshed in the Volume 1 2019 Service Pack 1 release which is expected to be rolled out in the end of April, 2019. We appreciate your patience until then. 

Thanks, 

Christo