Skip to content
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

Fix: support date ranges for parameterized embeds #3681

Merged
merged 5 commits into from
Apr 7, 2019

Conversation

rauchy
Copy link
Contributor

@rauchy rauchy commented Apr 6, 2019

What type of PR is this? (check all applicable)

  • Refactor
  • Feature
  • Bug Fix
  • New Query Runner (Data Source)
  • New Alert Destination
  • Other

Description

Parsing of date ranges was unhandled in #3495, and is now fixed here, though I guess we should really toss this piece of code and consolidate.

Related Tickets & Documents

Reported by @HenroRitchie here, thanks!

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

@rauchy rauchy requested a review from arikfr April 6, 2019 11:29
@rauchy rauchy mentioned this pull request Apr 7, 2019
1 task
@rauchy rauchy requested a review from ranbena April 7, 2019 13:11
const removePrefix = ([k, v]) => [k.slice(2), v];
const toObject = (obj, [k, v]) => Object.assign(obj, { [k]: v });

export default () => Object.entries(parse(location.search))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this parsing function is really specific to redash query parameters, I would:

export default parseLocationSearch = () => Object.entries(parse(location.search));

export parseRedashQueryParameters = () => parseLocationSearch()
  .filter(onlyParameters)
  .map(removePrefix)
  .reduce(toObject, {});

Wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that most of the (non-lib) code in the project is Redash specific but we don't explicitly add "Redash" to function and class names, so I tend to disagree.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I agree that prefixing stuff with "Redash" in our codebase doesn't make sense, @ranbena has a point that this is not some generic query string parsing function but a specific one for parameters. It makes sense to name it accordingly, like "parametersFromQueryString" or something along this lines.

Copy link
Contributor

@ranbena ranbena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok @rauchy

@rauchy rauchy merged commit 47bf91e into master Apr 7, 2019
Copy link
Member

@arikfr arikfr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already merged, but it made sense to comment about this in the context of this PR.

@@ -76,6 +76,7 @@
"pivottable": "^2.15.0",
"plotly.js": "1.41.3",
"prop-types": "^15.6.1",
"qs": "^6.7.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You had to commit an updated package-lock.json file as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I wonder how that slipped. Should I do this in a new PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

@@ -0,0 +1,11 @@
import qs from 'qs';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file name doesn't follow the convention of filename = name of default export.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was unaware of that convention. This will be handled in #3687

const removePrefix = ([k, v]) => [k.slice(2), v];
const toObject = (obj, [k, v]) => Object.assign(obj, { [k]: v });

export default () => Object.entries(parse(location.search))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I agree that prefixing stuff with "Redash" in our codebase doesn't make sense, @ranbena has a point that this is not some generic query string parsing function but a specific one for parameters. It makes sense to name it accordingly, like "parametersFromQueryString" or something along this lines.

@rauchy
Copy link
Contributor Author

rauchy commented Apr 8, 2019

@arikfr

like "parametersFromQueryString" or something along this lines

A query is a model in Redash, a query can have multiple parameters, a query-string is a part of the url, parameters can be represented inside the query-string, sometimes the query-string is represented in our code as 'query', which has parameters. THIS IS NUTS.

harveyrendell pushed a commit to pushpay/redash that referenced this pull request Nov 14, 2019
* support date ranges for parameterized embeds

* add qs

* remove hideous implementation and use qs

* get rid of apiKey querystring parameter and introduce query-string
module
@guidopetri guidopetri deleted the fix-support-date-ranges-for-parameterized-embeds branch July 22, 2023 03:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants