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
This is something that becomes quite obvious when you chain multiple method calls as the isBefore/isAfter stand out like a sore thumb:
letbefore= momentNow()|>Moment.subtract(~duration=duration(1,`days));letdate= momentNow()|>Moment.add(~duration=duration(1,`days));
date |>Moment.isAfter(before);/* false */
date ->Moment.isAfter(before);/* true */
It seems that in the current API, the Moment instance is always passed last. However, in isAfter/isBefore, it seems the order of expected arguments is the opposite which results in having to use fast pipes to get the expected result.
This seems to be on purpose as the tests show but seems counterintuitive to me:
This is something that becomes quite obvious when you chain multiple method calls as the isBefore/isAfter stand out like a sore thumb:
It seems that in the current API, the Moment instance is always passed last. However, in isAfter/isBefore, it seems the order of expected arguments is the opposite which results in having to use fast pipes to get the expected result.
This seems to be on purpose as the tests show but seems counterintuitive to me:
To me if the current instance is always passed last, then I would expect
moment(2018) |> Moment.isAfter(2016)
to return trueThe text was updated successfully, but these errors were encountered: