-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feat] merge relative date refiner #430
Conversation
Hey @liamcain. Thank you for your work! |
Hi @wanasit, is there a review you forgot to submit? I don't see the comment you're referring to. Also just noticed that I had |
|
||
shouldMergeResults(textBetween: string, currentResult: ParsingResult, nextResult: ParsingResult): boolean { | ||
return ( | ||
textBetween.match(this.patternBetween()) != null && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is difficult to understand. Could we break this into multiple if-return-false? e.g.
if (<not match>) {
return false;
}
if (<not time ago>) {
return false;
}
...
return true;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point, this was confusing for me to read just a few days after having written it. Improved the code style here and added some more context to make it easier follow.
* - 2 weeks before 2020-02-13 | ||
* - 2 days after next Friday | ||
*/ | ||
export default class ENMergeDateRelativeRefiner extends MergingRefiner { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I think ENMergeRelativeDateRefiner
is more accurate and consistent with the other merge refiners
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to your suggest. I was also thinking ENMergeImpliedReferenceDateRefiner
might be more accurate, lmk what you think.
const PATTERN = new RegExp(`(${TIME_UNITS_PATTERN})\\s{0,5}(?:ago|before|earlier)(?=(?:\\W|$))`, "i"); | ||
const STRICT_PATTERN = new RegExp(`(${TIME_UNITS_PATTERN})\\s{0,5}ago(?=(?:\\W|$))`, "i"); | ||
export const PATTERN = new RegExp(`(${TIME_UNITS_PATTERN})\\s{0,5}(?:ago|before|earlier)(?=(?:\\W|$))`, "i"); | ||
export const STRICT_PATTERN = new RegExp(`(${TIME_UNITS_PATTERN})\\s{0,5}ago(?=(?:\\W|$))`, "i"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to export both strict and normal? could you export only the one we need?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted. I mostly did this out of laziness, but I agree that having more precise pattern matching here is better.
Ops. Sorry, I'm actually not very used to CR through Github ^^; |
@wanasit Thanks for the review! I addressed all your comments |
Summary
Adds support for more complex composite dates.