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
Version 2.0.0 added chainable behavior, however one note I immediately got is that the behavior of having to unwrap boolean values, either explicitly using the raw value, or implicitly using == is counter-intuitive. For example:
vardate=newSugar.Date('tomorrow');if(date.isValid().raw)// Explicitly unwraps chainableif(date.isValid()==true)// Implicitly unwraps chainable with "valueOf"if(date.isValid()===true)// Does not work as the chainable is not unwrappedif(date.isValid())// Does not work as the chainable is not unwrapped
As Sugar's date module is often seen on it's own, users who are only interested in dates (such as this user) may not (should not have to?) understand the chainable behavior.
This could potentially be improved by separating methods that return booleans and defining different behavior on them (i.e. always returning an unwrapped boolean). Note particularly that this would make Sugar more intuitive when compared to moment.js, which doesn't have to deal with this issue as it is only concerned with dates.
However this has a few possible issues:
It could potentially be more confusing as it breaks the promise that a chainable method will return a new chainable. Would this become "returns a new chainable unless the result is a boolean"?
It would differ from Underscore/Lodash whose _.chain method do essentially the same thing as Sugar does now by wrapping a raw value, and do not unwrap boolean types either. I'm not against this but it would need a decent justification.
The assumption here is that there is no value in chaining booleans, but is this actually true? Although it's unlikely that there are any boolean-specific methods would be particularly useful, a wrapped boolean still has type checking methods such as isArray etc available to it. If the return type is unknown for whatever reason, these methods may still be useful.
What about methods that return booleans or undefined (if any?). As a tangential issue, what about methods that return undefined or null? Should these be unwrapped too?