Skip to content

Add 'data-' attributes to <li>s with 3rd 'selection' param on ranges #76

Closed
wants to merge 1 commit into from

2 participants

@chadoh
chadoh commented Mar 12, 2013

In order to hook daterangepicker into our existing app infrastructure,
we needed to be able to pass some custom keys with our ranges. These
keys, for us, correspond to filters defined on the backend that are
already used all over the app.

Really, this implementation feels backwards, but fixing it would require
major breaking changes with the current functionality of
daterangepicker. To us at PipelineDeals, it seems like a better
implementation would be: Have these 'custom keys' replace the current
range keys, and have a third parameter passed to ranges with the "human
name" of the range, which gets displayed in the UI.

I can schedule some time to add some docs for this feature, if you feel
it fits within the scope of daterangepicker.

@chadoh chadoh Add 'data-' attributes to <li>s with 3rd 'selection' param on ranges
In order to hook daterangepicker into our existing app infrastructure,
we needed to be able to pass some custom keys with our ranges. These
keys, for us, correspond to filters defined on the backend that are
already used all over the app.

Really, this implementation feels backwards, but fixing it would require
major breaking changes with the current functionality of
daterangepicker. To us at PipelineDeals, it seems like a better
implementation would be: Have these 'custom keys' replace the current
range keys, and have a third parameter passed to ranges with the "human
name" of the range, which gets displayed in the UI.

I can schedule some time to add some docs for this feature, if you feel
it fits within the scope of daterangepicker.
86b17fc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.