You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a variable is a float and set to a value that is the result of a math expression, the result can be an unfriendly value for display.
"Your store discount was $1.34254535" as opposed to "Your store discount was $1.34".
The runner.js code is not implemented in a way where it can distinguish between a variable being displayed or used in an expression.
The YS docs have this to say, which is not how things work in bondage.js and not good enough imo.
Numbers are always decimals (technically, floating point) regardless of what values you give them. This means if you give a variable the value of 1 when you get it back out from Yarn Spinner it will be 1.0.
This custom formatting should be part of the core engine in my opinion, but if that is asking too much, then the solution below would be a good trade-off, so devs have a way to implement variable formatting themselves.
A possible solution would be to extend the variable storage class to have another function called display, which would get the variable when it is being displayed. The runner would be refactored to call display() when appropriate. This would allow custom implementations of the variable storage class to handle custom formatting of variables for display purposes.
You may be wondering how a variable's formatting would be specified. This could be accomplished by implementing a custom variable model for your custom varuable storage class that isn't simply a variable, but instead a class with two properties, value and format. A custom command setvarformat could be added for setting the format for a variable. When display is called the function could check to see if a format is specified and then do the formatting or not, if none is specified.
The text was updated successfully, but these errors were encountered:
Here is an easier work around. Create a custom command that formats the variable and keep two copies of the variable, one for calculations and one for display. After setting the non-display variable, call the custom command to format the display variable. This is necessary when max precision is required for the calculations and not for displayed value.
If a variable is a float and set to a value that is the result of a math expression, the result can be an unfriendly value for display.
"Your store discount was $1.34254535" as opposed to "Your store discount was $1.34".
The runner.js code is not implemented in a way where it can distinguish between a variable being displayed or used in an expression.
The YS docs have this to say, which is not how things work in bondage.js and not good enough imo.
This custom formatting should be part of the core engine in my opinion, but if that is asking too much, then the solution below would be a good trade-off, so devs have a way to implement variable formatting themselves.
A possible solution would be to extend the variable storage class to have another function called display, which would get the variable when it is being displayed. The runner would be refactored to call display() when appropriate. This would allow custom implementations of the variable storage class to handle custom formatting of variables for display purposes.
You may be wondering how a variable's formatting would be specified. This could be accomplished by implementing a custom variable model for your custom varuable storage class that isn't simply a variable, but instead a class with two properties, value and format. A custom command setvarformat could be added for setting the format for a variable. When display is called the function could check to see if a format is specified and then do the formatting or not, if none is specified.
The text was updated successfully, but these errors were encountered: