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

EuiSuperDatePicker #1351

Merged
merged 42 commits into from
Dec 17, 2018
Merged

EuiSuperDatePicker #1351

merged 42 commits into from
Dec 17, 2018

Conversation

nreese
Copy link
Contributor

@nreese nreese commented Dec 6, 2018

Summary

This PR replaces the globalDatePicker pattern with a fully functional EuiSuperDatePicker component that can be used as the Kibana global date picker.

Checklist

  • This was checked in mobile
  • This was checked in IE11
  • This was checked in dark mode
  • Any props added have proper autodocs
  • Documentation examples were added
  • A changelog entry exists and is marked appropriately
  • This was checked for breaking changes and labeled appropriately
  • Jest tests were updated or added to match the most common scenarios
  • This was checked against keyboard-only and screenreader scenarios
  • This required updates to Framer X components

@cchaos
Copy link
Contributor

cchaos commented Dec 6, 2018

Wowsah! Can't wait to go through this one. I'll probably make this a quick pass tomorrow and anything that's just style related can be a follow-up PR so that this can unblock your Kibana implementation.

@cchaos
Copy link
Contributor

cchaos commented Dec 7, 2018

It's so fun to see it all hooked up. Thanks so much for doing this!

Visual check

  1. When showing the pretty format, can you spell out the full thing so that this says "Last 15 days" instead of "Last 15d"
    image

Basically anything they input from the quick select form should read out the same in the input. For instance, I applied Next / 160 / minutes from the quick select but the input then read now to ~ in 3 hours

  1. In the quick select, can you persist the last edit to that form? It always seems to revert back to Last / 15 / minutes

  2. Recently used date ranges should populate from the top not the bottom, meaning the most recent is at the top.

  3. When using the next / previous time window arrow, I think it's ok to keep the popover open so they can quickly keep shifting that window.

  4. After moving the time window, since you are showing "[date] to [date]" should it not be a pretty format but the actual date inputs?

screen shot 2018-12-07 at 10 36 08 am

Oh I see, that when I click "Show dates" it reverts to the date inputs, but then when I hit refresh, it goes back to the "[date] to [date]" format. Can we persist that any time it wants to show a "[date] to [date]" format, it just uses the date inputs? Having to keep clicking "Show dates" to modify these actual dates is quite cumbersome.

I think the main function of the time picker should be that by default it's always the two date inputs unless they use the quick select form from the popover.

It will also do a better job at displaying the full dates since the pretty format of "[date] to [date]" hardly shows much of the end date.

screen shot 2018-12-07 at 10 43 06 am

vs.

screen shot 2018-12-07 at 10 43 11 am

Even when using the Relative picker per date, it seems odd to me that on Refresh it turns it into a string instead of keeping the date inputs there.

I also find it harder to read with using "to" instead of the arrow and the spacing around each date.

  1. Is now to now valid? It's not showing as invalid.

screen shot 2018-12-07 at 10 56 34 am


If any of that is confusing or you want to talk it through again on zoom, just ping me. I'll start a code review now.

@cchaos
Copy link
Contributor

cchaos commented Dec 7, 2018

Another issue I just saw was that, other than the "__ to date" commonly used options, the rest of them (when showing their dates) don't look correct. It seems to be passing the same values to 'start' and 'end':

…w, now to now isInvalid, recenlty selected in reverse order
Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

I just concentrated the code review on the actual components and will leave the more complicated logic/utility bits for @chandlerprall to review :)

My comments were all mostly small things and can probably change after the fact (another PR). My main concerns are the ones listed above when it comes to interaction and the pretty format state.

src/components/date_picker/_index.scss Outdated Show resolved Hide resolved
src/components/date_picker/index.js Outdated Show resolved Hide resolved

EuiSuperDatePicker.defaultProps = {
from: 'now-15m',
to: 'now',
Copy link
Contributor

Choose a reason for hiding this comment

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

This may too much work, but I find 'start' and 'end' to be more understandable than 'from' and 'to'. Maybe we could change them?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe let's just change these as the prop names for the larger component and not worry about the sub-components for now. But at least the consumer will only have knowledge of start and end needs.

@nreese
Copy link
Contributor Author

nreese commented Dec 10, 2018

@snide @cchaos That should be the last of the requested changes

@cchaos
Copy link
Contributor

cchaos commented Dec 10, 2018

Looks great, though I found one more thing :sorry:

When using the relative tab and I select try to change the units first (while quantity is still 0), it won't change. Can you let it accept any unit even when it's set to 0?

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

Ok I did a final review and tested in IE11 and Firefox. There are a few issues in each but nothing major. I'll still be doing a follow up design PR anyway, so I can take a look into those. But I think we're good to merge!

Thank you so much @nreese! This is definitely one of the best components we've built!

Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

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

Nice work @nreese!

@snide
Copy link
Contributor

snide commented Dec 12, 2018

Is this mergable @nreese? Actually got a request from @justinkambic to use it in something he's got for 6.6 (I know it won't get into the global scope, this is something different he's working on). I could likely get it into another PR I have going today for Kibana if so, then he could use it.

@nreese
Copy link
Contributor Author

nreese commented Dec 12, 2018

@snide I was waiting on a review from @chandlerprall before merging but if you think it should merge as-is, I can always address his feedback in a separate PR

@snide
Copy link
Contributor

snide commented Dec 12, 2018

No. I just totally forgot we had that part to do still. No worries.

package.json Outdated Show resolved Hide resolved
};
}

static getDerivedStateFromProps = (nextProps) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same thing here, overriding state

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Overriding the state is intended. The point is that when the props update, the state must update to reflect what is getting passed in.

};
}

static getDerivedStateFromProps = (nextProps) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Unfortunately, same case here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Overriding the state is intended. The point is that when the props update, the state must update to reflect what is getting passed in.

@nreese
Copy link
Contributor Author

nreese commented Dec 14, 2018

@chandlerprall After passing selected to EuiDatePicker in EuiAbsoluteTab, the following warning is displayed in the console. Any ideas why the proptypes check is failing?

screen shot 2018-12-14 at 2 30 47 pm

@nreese
Copy link
Contributor Author

nreese commented Dec 17, 2018

@chandlerprall This is ready for a another look

@XavierM
Copy link
Contributor

XavierM commented Dec 17, 2018

@nreese Should we also introduce kibana localization/i18n to this PR?

@nreese
Copy link
Contributor Author

nreese commented Dec 17, 2018

@nreese Should we also introduce kibana localization/i18n to this PR?

No, EUI is not ready to handle i18n yet but there is an open issue, #738. This component will need to be localized once that issue is resolve and an implementation is known

Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

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

Changes LGTM! Thanks @nreese !

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.

5 participants