Continuing from #2668.
Sketch file does not represent UI as symbols. Symbols in Sketch are like components in React.

Imagine if controls in Blueprint were developed as functions in one monolithic javascript file. Then in order to use a component the developer had to open a large javascript file, copy relevant code and paste into their application.

Given this import:

@import "node_modules/@blueprintjs/core/src/blueprint.scss";

Webpack is throwing an error

ERROR in ./~/css-loader!./~/postcss-loader!./~/resolve-url-loader!./~/sass-loader?sourceMap!./src/styles/app.scss
Module build failed: 
@import "../node_modules/bourbon/app/assets/stylesheets/bourbon";
^
      File to import not found or unreadable: ../node_modules/bourbon/app/assets/stylesheets/bourbon
Parent style sheet: /Users/dave/www/portalv3/node_modules/@blueprintjs/core/src/common/_font-imports.scss
      in /Users/dave/www/portalv3/node_modules/@blueprintjs/core/src/common/_font-imports.scss (line 4, column 1)
...

The path to ../node_modules/bourbon/app/assets/stylesheets/bourbon is invalid, as bourbon isn't installed as a dependency because it's listed under devDependencies. Is this library not intended to allow users to override the variables?

Many components (such as Menu) can take an href prop. This prop maps to the href value of an <a> tag. For many react projects that use client-side routing, anchor tags are replaced by <Link> (e.g. in react-router) components that ensure the routing happens client-side.

If the <Link> component is placed inside the text prop, everything behaves as expected, but React throws a warning for having nested <a> tags.

Perhaps we could supply our own component to be used in place of the <a> tag in these situations.

Environment

• Package version(s): "@blueprintjs/core": "^3.15.1", "typescript": "3.5.1"
• Browser and OS versions: Ubuntu 18.04, FireFox 67.0.2

Steps to reproduce

import { Hotkey, Hotkeys, HotkeysTarget } from "@blueprintjs/core";
@HotkeysTarget
export class MyComponent extends React.PureComponent<{}> {
     public render () { return <div>Hello there</div> };
     public renderHotkeys() {
        return <Hotkeys>
            <Hotkey
                combo="up"
                label="Up"
                onKeyDown={() => { alert('Need to go up'); } }
            />
        </Hotkeys>;
    }    
}

Actual behavior

The component cannot be rendered. I get an error that starts with this:

TypeError: class constructors must be invoked with |new|
HotkeysTargetClass
node_modules/@blueprintjs/core/lib/esm/components/hotkeys/hotkeysTarget.js:32

  29 | tslib_1.__extends(HotkeysTargetClass, _super);
  30 | 
  31 | function HotkeysTargetClass() {
> 32 |   return _super !== null && _super.apply(this, arguments) || this;
     | ^  33 | }
  34 | 
  35 | HotkeysTargetClass.prototype.componentWillMount = function () {

Full traceback available, but probably not needed.

Expected behavior

The component should be rendered and the hotkey should be working.

Fixes #365

Checklist

• [x] 🔥 Update documentation
• [x] how to handle the CSS API now?
  • Buttons, all the way down
  • Input Group CSS API examples
• [x] improve example
• [x] Callout still uses icon classes because it relies on ::before and position trickery
  • ~~can't resolve this without an API break~~ totally did it #2060
• [x] MenuItem icon color

Changes proposed in this pull request:

• generate-icons-source script now generates iconSvgPaths.tsx file with export const IconSvgPaths{16,20}: Record<IconName, string[]> where value is array of <path d="..." /> strings
• 🔥 IconName only includes short names. LegacyIconName extends it with long names.
  • I made this change for the Record type above to support indexing
  • open to a less-breaking approach, but i'd also love to drop support for the long names.
• 🔥 core Icon component now renders SVG content instead of span.pt-icon...
  • removed iconSize prop, replaced with width/height. this isn't totally ideal, I could use some help figuring out the ideal API here.

Reviewers should focus on:

• [x] what to do with the CSS icon API?
• [x] how to support 16px / 20px switch?

Follow-up work

• 🔥 refactor iconName?: IconName prop ⇒ icon?: IconName | JSX.Element? #2067
  • bunch of breaking changes here
  • necessary to support custom SVG icon components
• 🔥 IconName or LegacyIconName #2066
  • can we drop support for the long names pt-icon-time?
• download links in Icons list should use large icon for 20px download. requires #2066 so I can pass <Icon iconSize={20} ... /> in that case

It seems that [email protected] exports moment as a function by default but it's being imported with the syntax import * as moment from 'moment', yet this file https://github.com/palantir/blueprint/blob/master/packages/datetime/src/common/dateUtils.ts #calls moment as a function in multiple places, which leads to this error. Has anyone seen this or been able to reproduce? Might be missing something here...

Also obligatory shoutout for the awesome lib, thanks for all your hard work.

Bug report

• Package version(s): 1.14
• Browser and OS versions: OSX El Capitan

Steps to reproduce

1. Import DateRangeInput and pass in valid dates

Actual behavior

TypeError: moment is not a function is thrown

Expected behavior

Should not throw an error.

Fixes #213

Checklist

• [x] Include tests
• [x] ~Update documentation~ (will add language in a separate PR if we want it)
• [x] Add new example
• [x] Fix interaction regression w/ TruncatedPopover

Changes proposed in this pull request:

Behold: column and row reordering in Table.

Basic points:

• Reordering works only if selection is also enabled. If this assumption is bad, let me know.
• Reordering is performed by mousing down within a selected column header, then dragging. If reordering is enabled, it is no longer possible to deselect a column by clicking on its header. LMK how that feels; I don't love it yet.
• You can enable reordering for columns, rows, or both via Table props.
• You can reorder a single entity or a region of multiple entities (having FULL_COLUMNS or FULL_ROWS cardinality).
• You CANNOT reorder anything if there are multiple regions selected. It's too much of a pain for a v1 implementation, plus initial feedback suggested that no user will be able to predict what will happen anyway. We can revisit this later if we want.
• The Table does not handle the actual reordering! It simply emits (oldIndex, newIndex, length) and lets the caller pass in updated data.

Reviewers should focus on:

• High-level architecture. Does it look reasonable?
• One thing that felt a little gross was the introduction of a "reordering cursor overlay" that displays invisibly over the whole table while you're dragging to reorder. I couldn't think of a better way to guarantee that the cursor would appear as grabbing no matter where your mouse moved during the drag. LMK what you think.

Screenshot

Fixes #413

Checklist

• [x] Update documentation

@llorca @thisisalessandro

Reviewers should focus on:

• Wording in documentation - is this enough to show the variants of controls that we provide?
• Class naming

with .pt-inline

Checklist

• [x] Works with EditableName
• [x] Works with children content (spacing only)
  • Users will be responsible with using the pt-skeleton class on their header cell children
• [x] Update documentation
• [x] Includes tests

Changes proposed in this pull request:

Quick little thing. In the spirit of aggressively opening PRs and then asking for feedback, I propose that we change the default header-menu icon from pt-icon-more (···) to pt-icon-chevron-down (⌄), which looks and feels much more intuitive to me.

Also, I found it annoying that the icon looked the same whether you were hovering inside or outside of it within the header cell. This PR shows the icon with $pt-icon-color when you hover in the header cell but NOT within the icon, showing $pt-icon-color-hover only when you mouse over the clickable icon area.

Before:

After (Light theme):

After (Dark theme):

For what it's worth, these changes seem consistent with the original mocks for the Table from way back when (although the chevron in the mocks feels too big):

Reviewers should focus on:

• I think the second piece (the hover/non-hover color) should merge regardless—do you agree?
• Do you like the icon change?

Checklist

• [x] Enable CircleCI for your fork
• [ ] Include tests
• [ ] Update documentation

Changes proposed in this pull request:

This adds a very general MultiRangeSlider component that ultimately should be able to subsume the Slider and RangeSlider components.

Notes about the component API:

• Instead of taking a value/values the component takes a list of handles specified by props. Each handle has:
• value - where it gets placed on the slider
• type - specifies how the slider handle should be displayed
  • "full" - handle appears like it does in a Slider (default)
  • "lower" - handle appears like the first slider in a RangeSlider
  • "upper" - handle appears like the second slider in a RangeSlider
• trackIntent{Above,Below} specifies the color of the track fill above and below (numerically) of the given handle.

Handles are always displayed in ascending numeric order and the values that are returned by onChange and onRelease are always sorted.

In addition, MultiRangeSlider takes a defaultTrackIntent prop which is used in the resolution of how to render the color of the track between two given handles. The way that this is resolved is as follows (and is one of my concerns about the API).

• If the left handle has an above intent, use that
• If the right handle has a below intent, use that
• If the component has a default intent, use that
• Otherwise don't color that section

Important: Note that there is a difference between the NONE intent and the absence of an intent entirely (undefined). The former will render a gray track between the two handles and the latter will fall-through to the next color in the hierarchy above.

I previously allowed the specification of colors instead of intents but that didn't seem very blueprint-y.

Reviewers should focus on:

I have explicitly not written tests/docs for this yet, as I would first like to iterate on the API as I'm not convinced what I've written is particularly nice (worked for our use case but don't know if it generalizes well). Once we've iterated and nailed down an API I will gladly write tests and docs for this component.

I've written some questions in the code, but one additional question I have is should this component live in labs first to incubate before moving into core?

Not addressed in this PR (requires follow-up):

To keep this PR simple(r) and easy(er) to review, I have not made many changes to the existing slider components but in 1-2 follow up PRs I would like to:

1. Refactor Slider and RangeSlider to be simple wrappers around MultiRangeSlider
2. Remove CoreSlider and refactor into MultiRangeSlider

The second one is questionable, especially if there are plans to add a slider that does not fit into the multi range slider model.

Screenshots

Two tailed slider:

Disabled:

One tailed:

Weird:

Vertical:

In action:

Fixes #3369

Checklist

• [x] Includes tests
• [x] Update documentation

Changes proposed in this pull request:

See https://github.com/palantir/blueprint/issues/3369#issuecomment-469887277

I didn't add any tests because it seems like there's no tests for scrolling, and I wasn't sure how to best write such a test:

https://github.com/palantir/blueprint/blob/b6c1518ea2f524accfba8045ce6f22cac7c5b56e/packages/select/test/queryListTests.tsx#L215-L217

Reviewers should focus on:

getActiveElement being exposed as desired

Screenshot

Problem

If you change body class on client-side with JS, to determine theme automatically, you'll get flickering.

Something like this, as an example:

Which means: white by default, dark only when page will let JS do its work.

Instead of JS, it should be done with CSS media queries. This will remove flickering forever.

Solution

Good example how it's done is Github Primer CSS, look here:

https://primer.style/css/support/theming

They have options: dark, light, and auto, – first two forcing the style, say, when you need to set it from user preferences. The last one will let browser determine it automatically... FROM CSS, using media queries, – that's important one again, because it will save you from getting flickering bug when browser tries to automatically set proper theme. Automatic theming shouldn't be done JS-way. Should be done CSS-way.

Similar issues

Another similar issue (solving this one will solve his use-case too):

• https://github.com/palantir/blueprint/issues/4164

Environment

• Package version(s): ^3.15.1
• Operating System: macOS Ventura 13.0.1
• Browser name and version: Firefox 108.0.1

Code Sandbox

Link to a minimal repro: https://codesandbox.io/s/jolly-nash-tyt67e?file=/src/index.tsx

Steps to reproduce

1. Press TAB until month / year is focused

Actual behavior

On Firefox, focus never reaches month/year

Expected behavior

Month/Year should be focusable by pressing Tab

Possible solution

Make it focusable?

Bug preview

Bumps react-day-picker from 7.4.9 to 8.4.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps postcss-loader from 7.0.1 to 7.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps ts-loader from 9.4.1 to 9.4.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.