returnType config option allows return of a moment() value to ngModel #39
Conversation
…tead of a date as desired (as well as karma tests)
|
+1 |
|
Thanks for the PR! Sorry I have not gotten to this one for so long. I'm wondering if this can be implemented without a configuration option? When first opened, we can grab the typeof the model ('date', 'string', 'number', or 'moment') and just use that type to determine the return type. Thoughts? |
|
Any news on pull request? Seems to be very useful... |
dalelotts
added
Waiting for response
Support Question
|
I haven't really looked at this one in detail. I didn't hear back from the OP or anyone else so it's not clear that there is much of a need for this. |
|
Apologies for the delay in responding. I ended up going with another typeof could be used to make it more flexible but I would be concerned that On Wed, Nov 19, 2014 at 02:38 Dale Lotts [email protected] wrote:
|
|
+1 |
…g data in the model Accepts any string value, but the following values have special meaning (these values are case sensitive) : * ```'Date'``` stores a Date instance in the model. Will accept Date, moment, milliseconds, and ISO 8601 strings as initial input from the model * ```'moment'``` stores a moment instance in the model. Accepts the same initial values as ```Date``` * ```'milliseconds'``` store the epoch milliseconds (since 1-1-1970) in the model. Accepts the same initial values as ```Date``` -Any other value is considered a format string. -When accepting values from, and saving values to the model, this directive tries to be as flexible as possible. Dates, moments, and milliseconds are all accepted as input no matter what you specify for ```modelType```. However, strings are problematic and often lose timezone information, so use caution when storing strings. -If you must use a string, be aware that the format stored in the model must exactly match the format specified in ```modelType```. For example, the value in the model is ```'2015-12-31'``` then using ```modelType: 'MM-DD-YYYY'``` will cause an exception. -I predict that I will regret adding this feature. closes #241, closes #190, closes #39
…g data in the model Accepts any string value, but the following values have special meaning (these values are case sensitive) : * ```'Date'``` stores a Date instance in the model. Will accept Date, moment, milliseconds, and ISO 8601 strings as initial input from the model * ```'moment'``` stores a moment instance in the model. Accepts the same initial values as ```Date``` * ```'milliseconds'``` store the epoch milliseconds (since 1-1-1970) in the model. Accepts the same initial values as ```Date``` -Any other value is considered a format string. -When accepting values from, and saving values to the model, this directive tries to be as flexible as possible. Dates, moments, and milliseconds are all accepted as input no matter what you specify for ```modelType```. However, strings are problematic and often lose timezone information, so use caution when storing strings. -If you must use a string, be aware that the format stored in the model must exactly match the format specified in ```modelType```. For example, the value in the model is ```'2015-12-31'``` then using ```modelType: 'MM-DD-YYYY'``` will cause an exception. -I predict that I will regret adding this feature. closes #241, closes #190, closes #39
|
@ilkelma good point, after doing some digging I found that it is quite frequent that the data going in |
…g data in the model Accepts any string value, but the following values have special meaning (these values are case sensitive) : * 'Date' stores a Date instance in the model. Will accept Date, moment, milliseconds, and ISO 8601 strings as initial input from the model * 'moment'stores a moment instance in the model. Accepts the same initial values as ```Date``` * 'milliseconds' store the epoch milliseconds (since 1-1-1970) in the model. Accepts the same initial values as ```Date``` -Any other value is considered a format string. -When accepting values from, and saving values to the model, this directive tries to be as flexible as possible. Dates, moments, and milliseconds are all accepted as input no matter what you specify for ```modelType```. However, strings are problematic and often lose timezone information, so use caution when storing strings. -If you must use a string, be aware that the format stored in the model must exactly match the format specified in ```modelType```. For example, the value in the model is ```'2015-12-31'``` then using ```modelType: 'MM-DD-YYYY'``` will cause an exception. -I predict that I will regret adding this feature. closes #241, closes #190, closes #39
|
Closing since I believe this functionality is included in develop branch and it now has merge conflicts. |
(First pull request so bear with me if I've done something wrong)
As wlingke stated in issue #30 moment is used for formatting and parsing already and thus this fits very easily within an angular app that makes use of moment for date storage. My use case is similar to his in that I need to store the ngModel value as a moment and not a date.
From a usability standpoint the way I've implemented it the default is to behave as it does now, returning a js date object. It can then be changed by passing in returnType: 'moment' to the directive's configuration.
I've included karma tests as well.