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

Add presetted ranges to DateRange and DateTimeRange inputs #3781

Closed
wants to merge 4 commits into from

Conversation

gabrieldutra
Copy link
Member

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

  • Feature

Description

This is related to the first part of #3009, it adds a few presetted options (from Antd presetted ranges) to DateRange and DateTimeRange inputs.

I tried to think the ranges that could be useful (and the ones suggested on the issue :)), thought add suggestions if you have any 🙂.

Related Tickets & Documents

#3009

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

date-ranges-presetted-ranges

date-ranges-predefined-ranges

import { react2angular } from 'react2angular';
import DatePicker from 'antd/lib/date-picker';
import { clientConfig } from '@/services/auth';
import { Moment } from '@/components/proptypes';

const { RangePicker } = DatePicker;

export const PRESETTED_RANGES = {
Copy link
Member Author

Choose a reason for hiding this comment

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

It seemed interesting to export here since Date Time Ranges will basically have the same Presetted ranges + its specific ones (with time included in the ranges).

Copy link
Contributor

Choose a reason for hiding this comment

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

With this implementation the presets could go "stale" since they're calculated on page load (right?). Ideally should be calculated on preset click / calendar open. But it's unlikely so let's just keep it in mind.

Copy link
Member Author

Choose a reason for hiding this comment

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

I can use the function notation instead to avoid this :)

@gabrieldutra gabrieldutra self-assigned this May 8, 2019
@ranbena
Copy link
Contributor

ranbena commented May 9, 2019

@gabrieldutra this is really great!

A few thoughts:

  1. In order to minimize preset UI bloat, perhaps limit to one row along with a "more..." button that opens up all suggestions. Not a must, not so simple to implement.
  2. "This/Last week" mandates that the calendar be set to the correct "workweek" (starting Mon or Sun). Is that automatic? Is it configurable?
  3. "Today" might be confused for a "dynamic" setting (day of query run) instead of the actual "static" (day of preset click). Same goes for "Last X" presets. Wdyt?

@gabrieldutra
Copy link
Member Author

In order to minimize preset UI bloat, perhaps limit to one row along with a "more..." button that opens up all suggestions. Not a must, not so simple to implement.

I tried to keep it with less than 2 rows for this reason. Unfortunately there's no easy way to implement the "more..." 😕. It would require to use Antd's renderExtraFooter and basically do again the ranges feature... Let's just keep it without many options for now (It's possible that this feature come up from Ant meanwhile).

"This/Last week" mandates that the calendar be set to the correct "workweek" (starting Mon or Sun). Is that automatic? Is it configurable?

According to moment's docs: "As of version 2.1.0, moment#startOf('week') uses the locale aware week start day.". The default seems to be en (which leads to Sun-Sat), but this can be changed using moment.locale. Wdyt?

"Today" might be confused for a "dynamic" setting (day of query run) instead of the actual "static" (day of preset click). Same goes for "Last X" presets. Wdyt?

There's indeed a chance it is confusing at first, but then it shows the specific days in the calendar and when you set to it, specific dates will show up. Dynamic settings are the second part of #3009, which I do have an idea to have a "Dynamic toggle" (should discuss this later in the issue).

The general idea here is to first give value without much, if this turns out to be confusing we can just remove those and let them only in the "Dynamic" options.

@ranbena
Copy link
Contributor

ranbena commented May 10, 2019

  1. 👍
  2. Sounds good. Maybe you can adjust the calendar itself while you're at it? 😬(Doesn't look so easy 😔)
    Btw, why is en-US set to Sun-Sat when should actually be Mon-Fri?
  3. 👍

@gabrieldutra
Copy link
Member Author

Btw, why is en-US set to Sun-Sat when should actually be Mon-Fri?

It's not considering work weekdays, but the whole week ^^ (I think this is what you expect when considering "This/Last week")

@arikfr
Copy link
Member

arikfr commented May 11, 2019 via email

@gabrieldutra
Copy link
Member Author

Actually in this context, I think people expect a work week.

Can this be a point of conflict too 🤔 ? I've reached some friends that use Redash and this can be more confusing than I initially thought...

  • Future dates may not be expected (so I just removed the 'This' ones)
  • The people from Brazil expected "Last week" to be the whole week, but had the following points of conflict: - It could be interpreted the same as 'Last 7 days'; - One actually preferred Mon-Sun over Sun-Mon (even though the second was expected);

A conclusion is that this will depend a lot from each business model, but for this part this is not that relevant as this will be only a shorthand and people can learn from the dates that appear in there.

So for this part the options I see are:

  1. Remove 'Last week' as it's the most conflicting one;
  2. Let it there with a defined value from us (which should fit most people);
  3. Add the setting option, so users can define what is their "week";

To this part I'm supporting 1 or 2. In case the setting option becomes relevant when doing Part 2 of #3009, we can extend it here as well.

@arikfr
Copy link
Member

arikfr commented Jun 12, 2019

anything stopping us from merging this?

@ranbena
Copy link
Contributor

ranbena commented Jun 12, 2019

anything stopping us from merging this?

I suggest to actually bundle these presets along with #3009 instead.

@gabrieldutra
Copy link
Member Author

Closing in favor of #3904

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