-
Notifications
You must be signed in to change notification settings - Fork 843
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
Downgraded lodash 3.10.1 (to align with Kibana) #359
Conversation
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.
lgtm
Thanks for migrating to Kibana's version of lodash
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 good, but had a couple questions!
@@ -1,5 +1,5 @@ | |||
import React from 'react'; | |||
import { isString } from 'lodash'; | |||
import { isString } from '../../services/predicate'; |
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.
Can we export the predicates from the root modules, services
?
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.
I can... thought about it... decided not to... but I can still do that.
Why decided not to? With generic services it somewhat feels off to export ALL possible utility functions under one module. the services sub-modules really don't have anything in common aside from the fact that they're all a bunch of utilities. To me it feels more appropriate to refer to the specific module when importing utilities.
But... that's my opinion... if you insist I can still export all to the higher services module
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.
I think you're right. In fact we should probably apply this pattern to the rest of the submodules under services
.
isDate, | ||
isNumber, | ||
isNaN, | ||
} from 'lodash'; |
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.
Why not remove lodash entirely? Can we internalize these functions?
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.
we should... but it'll have to wait to a different pr... (there's more to this when it comes to removing lodash... we'll need to remove other usages as well - e.g. _.get
)
- created a `predicate` module that exports all predicate function (e.g. `isString`, `isFunction`,...) - created `isNil` predicate - `sortable_properties` no longer uses lodash `sortBy` and uses our comparators instaed this change should enable using tables in Kibana.
- created a `predicate` module that exports all predicate function (e.g. `isString`, `isFunction`,...) - created `isNil` predicate - `sortable_properties` no longer uses lodash `sortBy` and uses our comparators instaed this change should enable using tables in Kibana.
predicate
module that exports all predicate function (e.g.isString
,isFunction
,...)isNil
predicatesortable_properties
no longer uses lodashsortBy
and uses our comparators instaedthis change should enable using tables in Kibana.