Option to disable abbreviations introduced in 2.5.0?
Nantris opened this issue · comments
As a user types "1 month" in our app, the fact that "1 m" is initially recognized as minute creates some ugliness as the text starts out for 1 minute from the current time, then updates to 1 month.
All of the single unit abbreviations added in 2.5.0 - as well as the "mo" abbreviation for month are causing problems in our application.
I'd be happy enough with an option to disable all abbreviations - since this also led to me finding some edge cases that feel buggy in our application in 2.4.2. For example in 1 mon is resolved as if a user wrote on mon(day)
Hello. Sorry for my very late reply.
It's a reasonable request, but I want to understand the problem more.
- So, you must also handle an incomplete sentence in your app? I think if a user is typing "1 m" and still typing, it could be "1 minute", "1 month", or "1 m 2s". We can only wait for them to complete the sentence first, right?
- Also, Chrono would not recognize "1 m" alone as a date. It would require some prefix e.g. "+1m" or "in 1m". Could you explain how did you make it recognize "1 m" in your case?
Hey @wanasit, thanks so much for your reply and again for the incredible work!
In our app we show the user a preview of the reminder they're creating. It's at this stage, during previewing, that these abbreviations become problematic.
A user may begin to type something like remind me in 1 m - and their intention may be to complete that as remind me in 1 month to do some thing - but briefly it is interpreted as 1 minute. It causes some ugly jittering in the preview as it jumps from minute to month, when ideally the preview would not even be appearing at this stage because in 1 m is not something we want to interpret as a time. Once there is a time match though, the previewer is shown and there's no good way to weed out the abbreviations at that stage.
I tried debouncing our calls to chrono-node, but I haven't been able to adequately remedy the issue like that.
@slapbox Could you take a look at the change in 787c41b?
The strict mode now won't allow abbreviations on the timeunits. For your use-case, if you need to allow casual, you'd have to customize Chrono or replacing or adding those parsers. e.g.:
const custom = chrono.en.casual.clone();
const index = custom.parsers.findIndex((r) => r instanceof ENTimeUnitCasualRelativeFormatParser);
custom.parsers[index] = new ENTimeUnitCasualRelativeFormatParser(/*useAbbreviations*/false);
custom.parse("next 5m") // should be empty
custom.parse("next 5 minutes") // has some results
...
Would this work for your use-case?
Thank you again for your great work @wanasit! It would be workable but it does have some significant downsides to have to disable all abbreviations.
For example, in 5m is pretty universally considered to be in 5 minutes and 90s is pretty universally regarded as 90 seconds. Although I do agree that's a helpful option, the option has some tradeoffs.
I wonder what you'd think of an option to only allow abbreviations directly attached to numbers? For example in 5m is in 5 minutes but in 5 m would be unrecognized. That might be the best of both worlds. I apologize of course for not sharing this revelation sooner; it was not until I was looking through your commit that this idea came to me.
Right now I'm leaning towards disabling all abbreviations if we have to go that route, but it would be great to be able to tell users "in 5 m will not work, but in 5m will`".