-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Improve engine view matcher with new pattern syntax #9694
Conversation
82fedd6
to
b061792
Compare
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.
Looks pretty good 👍🏻
TBC
// eslint-disable-next-line dot-notation | ||
if ( isPlainObject( pattern ) && pattern[ 'key' ] && pattern[ 'value' ] ) { | ||
return pattern; | ||
} | ||
|
||
// Assume the pattern is either String or RegExp. | ||
return { key: pattern, value: 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.
What if someone provided pattern = { value: 'red' }
or pattern = { key: 'color' }
? I'm wondering if we need some handling for that, maybe throw an error if pattern is an object but doesn't include key
and value
properties?
I'm not sure if checking pattern[property]
is enough, as it may have falsy value like pattern = { key: 'data-foo', value: '' }
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.
It would be also good to have some test coverage for that.
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 seems to not be resolved yet.
// eslint-disable-next-line dot-notation | ||
if ( isPlainObject( pattern ) && pattern[ 'key' ] && pattern[ 'value' ] ) { | ||
return pattern; | ||
} | ||
|
||
// Assume the pattern is either String or RegExp. | ||
return { key: pattern, value: 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.
This seems to not be resolved yet.
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.
Seems like we are also missing unit tests for regexp/string pattern full properties, like:
const match = {
attributes: /^data-.*$/,
styles: 'margin'
}
Uh, actually I see that a similar test for class names (on |
526d5d7
to
0c9267f
Compare
@maxbarnas I've rewritten a bit of documentation for new matcher options. It's more organized now so should be more readable for users. Could you take a look at these changes if everything is ok? 84f971f |
039036f
to
ea439f1
Compare
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.
🎉
Suggested merge commit message (convention)
Feature (engine): Improved engine view matcher with new pattern syntax allowing to match attribute keys using regular expressions. Unified pattern syntax between attributes, styles, and classes. Closes #9872.
Feature (engine): Added special
expand
option toStylesMap.getStyleNames()
and viewElement.getStyleNames()
methods allowing to expand shorthand style properties.Additional information
StylesProcessor
will be handled in the follow-up: Add tests toStylesProcessor
#9811.style
andclass
attributes is reverted back to original form. There is a follow-up, where we'll decide how to approach this: Normalize further patterns passed to Matcher #9813.