chore: upgrade to prettier v2 + enforce import types (#21013)Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
## Description
This PR upgrades Prettier to v2 + enforces TypeScript’s [`import
type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export)
syntax where applicable. It’s submitted as a separate PR so we can merge
it easily.
As a part of this PR, we reformat the codebase heavily:
- add `import type` everywhere where it’s required, and
- re-format the code to account for Prettier 2’s breaking changes:
https://prettier.io/blog/2020/03/21/2.0.0.html#breaking-changes
This PR is submitted against `release` to make sure all new code by team
members will adhere to new formatting standards, and we’ll have fewer
conflicts when merging `bundle-optimizations` into `release`. (I’ll
merge `release` back into `bundle-optimizations` once this PR is
merged.)
### Why is this needed?
This PR is needed because, for the Lodash optimization from
https://github.com/appsmithorg/appsmith/commit/7cbb12af886621256224be0c93e6a465dd710ad3,
we need to use `import type`. Otherwise, `babel-plugin-lodash` complains
that `LoDashStatic` is not a lodash function.
However, just using `import type` in the current codebase will give you
this:
<img width="962" alt="Screenshot 2023-03-08 at 17 45 59"
src="https://user-images.githubusercontent.com/2953267/223775744-407afa0c-e8b9-44a1-90f9-b879348da57f.png">
That’s because Prettier 1 can’t parse `import type` at all. To parse it,
we need to upgrade to Prettier 2.
### Why enforce `import type`?
Apart from just enabling `import type` support, this PR enforces
specifying `import type` everywhere it’s needed. (Developers will get
immediate TypeScript and ESLint errors when they forget to do so.)
I’m doing this because I believe `import type` improves DX and makes
refactorings easier.
Let’s say you had a few imports like below. Can you tell which of these
imports will increase the bundle size? (Tip: it’s not all of them!)
```ts
// app/client/src/workers/Linting/utils.ts
import { Position } from "codemirror";
import { LintError as JSHintError, LintOptions } from "jshint";
import { get, isEmpty, isNumber, keys, last, set } from "lodash";
```
It’s pretty hard, right?
What about now?
```ts
// app/client/src/workers/Linting/utils.ts
import type { Position } from "codemirror";
import type { LintError as JSHintError, LintOptions } from "jshint";
import { get, isEmpty, isNumber, keys, last, set } from "lodash";
```
Now, it’s clear that only `lodash` will be bundled.
This helps developers to see which imports are problematic, but it
_also_ helps with refactorings. Now, if you want to see where
`codemirror` is bundled, you can just grep for `import \{.*\} from
"codemirror"` – and you won’t get any type-only imports.
This also helps (some) bundlers. Upon transpiling, TypeScript erases
type-only imports completely. In some environment (not ours), this makes
the bundle smaller, as the bundler doesn’t need to bundle type-only
imports anymore.
## Type of change
- Chore (housekeeping or task changes that don't impact user perception)
## How Has This Been Tested?
This was tested to not break the build.
### Test Plan
> Add Testsmith test cases links that relate to this PR
### Issues raised during DP testing
> Link issues raised during DP testing for better visiblity and tracking
(copy link from comments dropped on this PR)
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
---------
Co-authored-by: Satish Gandham <hello@satishgandham.com>
Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
2023-03-16 11:41:47 +00:00
|
|
|
import type { AppState } from "@appsmith/reducers";
|
2023-05-19 18:37:06 +00:00
|
|
|
import { Icon } from "design-system";
|
chore: upgrade to prettier v2 + enforce import types (#21013)Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
## Description
This PR upgrades Prettier to v2 + enforces TypeScript’s [`import
type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export)
syntax where applicable. It’s submitted as a separate PR so we can merge
it easily.
As a part of this PR, we reformat the codebase heavily:
- add `import type` everywhere where it’s required, and
- re-format the code to account for Prettier 2’s breaking changes:
https://prettier.io/blog/2020/03/21/2.0.0.html#breaking-changes
This PR is submitted against `release` to make sure all new code by team
members will adhere to new formatting standards, and we’ll have fewer
conflicts when merging `bundle-optimizations` into `release`. (I’ll
merge `release` back into `bundle-optimizations` once this PR is
merged.)
### Why is this needed?
This PR is needed because, for the Lodash optimization from
https://github.com/appsmithorg/appsmith/commit/7cbb12af886621256224be0c93e6a465dd710ad3,
we need to use `import type`. Otherwise, `babel-plugin-lodash` complains
that `LoDashStatic` is not a lodash function.
However, just using `import type` in the current codebase will give you
this:
<img width="962" alt="Screenshot 2023-03-08 at 17 45 59"
src="https://user-images.githubusercontent.com/2953267/223775744-407afa0c-e8b9-44a1-90f9-b879348da57f.png">
That’s because Prettier 1 can’t parse `import type` at all. To parse it,
we need to upgrade to Prettier 2.
### Why enforce `import type`?
Apart from just enabling `import type` support, this PR enforces
specifying `import type` everywhere it’s needed. (Developers will get
immediate TypeScript and ESLint errors when they forget to do so.)
I’m doing this because I believe `import type` improves DX and makes
refactorings easier.
Let’s say you had a few imports like below. Can you tell which of these
imports will increase the bundle size? (Tip: it’s not all of them!)
```ts
// app/client/src/workers/Linting/utils.ts
import { Position } from "codemirror";
import { LintError as JSHintError, LintOptions } from "jshint";
import { get, isEmpty, isNumber, keys, last, set } from "lodash";
```
It’s pretty hard, right?
What about now?
```ts
// app/client/src/workers/Linting/utils.ts
import type { Position } from "codemirror";
import type { LintError as JSHintError, LintOptions } from "jshint";
import { get, isEmpty, isNumber, keys, last, set } from "lodash";
```
Now, it’s clear that only `lodash` will be bundled.
This helps developers to see which imports are problematic, but it
_also_ helps with refactorings. Now, if you want to see where
`codemirror` is bundled, you can just grep for `import \{.*\} from
"codemirror"` – and you won’t get any type-only imports.
This also helps (some) bundlers. Upon transpiling, TypeScript erases
type-only imports completely. In some environment (not ours), this makes
the bundle smaller, as the bundler doesn’t need to bundle type-only
imports anymore.
## Type of change
- Chore (housekeeping or task changes that don't impact user perception)
## How Has This Been Tested?
This was tested to not break the build.
### Test Plan
> Add Testsmith test cases links that relate to this PR
### Issues raised during DP testing
> Link issues raised during DP testing for better visiblity and tracking
(copy link from comments dropped on this PR)
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
---------
Co-authored-by: Satish Gandham <hello@satishgandham.com>
Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
2023-03-16 11:41:47 +00:00
|
|
|
import type { Placement, PopperOptions } from "popper.js";
|
|
|
|
|
import PopperJS from "popper.js";
|
2021-06-01 12:07:16 +00:00
|
|
|
import React, { useEffect, useMemo, useRef } from "react";
|
|
|
|
|
import { createPortal } from "react-dom";
|
|
|
|
|
import { getThemeDetails, ThemeMode } from "selectors/themeSelectors";
|
|
|
|
|
import styled, { ThemeProvider } from "styled-components";
|
2021-09-13 12:35:05 +00:00
|
|
|
import { generateReactKey } from "utils/generators";
|
2021-06-01 12:07:16 +00:00
|
|
|
import { draggableElement } from "./utils";
|
2020-06-04 13:49:22 +00:00
|
|
|
|
2023-10-11 07:35:24 +00:00
|
|
|
export interface PopperProps {
|
2022-02-18 12:26:09 +00:00
|
|
|
boundaryParent?: Element | PopperJS.Boundary;
|
|
|
|
|
parentElement?: Element | null;
|
2020-06-04 13:49:22 +00:00
|
|
|
zIndex: number;
|
2019-10-21 11:40:24 +00:00
|
|
|
isOpen: boolean;
|
2022-10-14 04:53:31 +00:00
|
|
|
borderRadius?: string;
|
2021-03-29 15:47:22 +00:00
|
|
|
themeMode?: ThemeMode;
|
2020-01-02 12:42:02 +00:00
|
|
|
targetNode?: Element;
|
2021-04-28 10:28:39 +00:00
|
|
|
children: JSX.Element | null;
|
2021-07-20 05:18:58 +00:00
|
|
|
renderDragBlock?: JSX.Element;
|
|
|
|
|
renderDragBlockPositions?: {
|
|
|
|
|
left?: string;
|
|
|
|
|
top?: string;
|
|
|
|
|
zIndex?: string;
|
|
|
|
|
position?: string;
|
|
|
|
|
};
|
2023-03-04 07:25:54 +00:00
|
|
|
style?: React.CSSProperties;
|
2020-06-04 13:49:22 +00:00
|
|
|
placement: Placement;
|
|
|
|
|
modifiers?: Partial<PopperOptions["modifiers"]>;
|
2021-03-29 15:47:22 +00:00
|
|
|
isDraggable?: boolean;
|
|
|
|
|
disablePopperEvents?: boolean;
|
2021-09-13 12:35:05 +00:00
|
|
|
cypressSelectorDragHandle?: string;
|
2022-10-14 04:53:31 +00:00
|
|
|
portalContainer?: Element;
|
2021-03-29 15:47:22 +00:00
|
|
|
position?: {
|
|
|
|
|
top: number;
|
|
|
|
|
left: number;
|
|
|
|
|
};
|
|
|
|
|
onPositionChange?: (position: { top: number; left: number }) => void;
|
2023-02-09 11:09:54 +00:00
|
|
|
setPosition?: (e: any) => void;
|
|
|
|
|
setIsDragging?: (e: any) => void;
|
|
|
|
|
isDragging?: boolean;
|
|
|
|
|
customParent?: Element | undefined;
|
|
|
|
|
editorRef?: React.RefObject<HTMLDivElement>;
|
2021-07-07 03:46:16 +00:00
|
|
|
// DraggableNode?: any;
|
2023-10-11 07:35:24 +00:00
|
|
|
}
|
2019-10-21 11:40:24 +00:00
|
|
|
|
2022-10-14 04:53:31 +00:00
|
|
|
const PopperWrapper = styled.div<{ zIndex: number; borderRadius?: string }>`
|
2020-12-24 04:32:25 +00:00
|
|
|
z-index: ${(props) => props.zIndex};
|
2019-10-21 11:40:24 +00:00
|
|
|
position: absolute;
|
2022-10-14 04:53:31 +00:00
|
|
|
border-radius: ${(props) => props.borderRadius || "0"};
|
|
|
|
|
box-shadow: 0 6px 20px 0px rgba(0, 0, 0, 0.15);
|
2023-02-09 11:09:54 +00:00
|
|
|
|
|
|
|
|
&&&:hover .drag-handle-block {
|
|
|
|
|
display: flex;
|
|
|
|
|
}
|
2019-10-21 11:40:24 +00:00
|
|
|
`;
|
|
|
|
|
|
2021-03-29 15:47:22 +00:00
|
|
|
const DragHandleBlock = styled.div`
|
|
|
|
|
cursor: grab;
|
2021-07-07 03:46:16 +00:00
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
justify-content: center;
|
|
|
|
|
width: 43px;
|
|
|
|
|
height: 28px;
|
|
|
|
|
z-index: 3;
|
2023-05-19 18:37:06 +00:00
|
|
|
background-color: var(--ads-v2-color-bg);
|
|
|
|
|
border-radius: var(--ads-v2-border-radius);
|
2023-02-09 11:09:54 +00:00
|
|
|
position: relative;
|
|
|
|
|
top: -15px;
|
|
|
|
|
pointer-events: auto;
|
2021-07-07 03:46:16 +00:00
|
|
|
|
2023-05-19 18:37:06 +00:00
|
|
|
:hover {
|
|
|
|
|
background-color: var(--ads-v2-color-bg-subtle);
|
2021-07-07 03:46:16 +00:00
|
|
|
}
|
2021-03-29 15:47:22 +00:00
|
|
|
`;
|
|
|
|
|
|
2023-10-11 07:35:24 +00:00
|
|
|
interface PopperDragHandleProps {
|
|
|
|
|
dragFn?: (val: boolean) => void;
|
|
|
|
|
}
|
2021-03-29 15:47:22 +00:00
|
|
|
|
2019-10-21 11:40:24 +00:00
|
|
|
/* eslint-disable react/display-name */
|
|
|
|
|
export default (props: PopperProps) => {
|
2023-02-09 11:09:54 +00:00
|
|
|
const contentRef = useRef<HTMLDivElement>(null);
|
2021-09-13 12:35:05 +00:00
|
|
|
const popperIdRef = useRef(generateReactKey());
|
|
|
|
|
const popperId = popperIdRef.current;
|
|
|
|
|
|
2023-02-09 11:09:54 +00:00
|
|
|
const onPositionChangeFn = (e: any) => {
|
|
|
|
|
if (contentRef.current && !!props.setPosition) {
|
|
|
|
|
contentRef.current.style.transform = "unset";
|
|
|
|
|
contentRef.current.style.top = e.top + "px";
|
|
|
|
|
contentRef.current.style.left = e.left + "px";
|
|
|
|
|
|
|
|
|
|
props.setPosition(e);
|
|
|
|
|
|
|
|
|
|
// add focus back to codemirror component.
|
|
|
|
|
if (
|
|
|
|
|
props?.editorRef &&
|
|
|
|
|
props?.editorRef?.current &&
|
|
|
|
|
props?.editorRef?.current?.children[1] &&
|
|
|
|
|
!!(props?.editorRef?.current?.children[1] as any)?.CodeMirror
|
|
|
|
|
)
|
|
|
|
|
(props?.editorRef?.current?.children[1] as any)?.CodeMirror.focus();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2021-03-29 15:47:22 +00:00
|
|
|
const {
|
2022-02-18 12:26:09 +00:00
|
|
|
boundaryParent = "viewport",
|
2023-10-11 07:14:38 +00:00
|
|
|
cypressSelectorDragHandle,
|
2021-03-29 15:47:22 +00:00
|
|
|
disablePopperEvents = false,
|
2023-10-11 07:14:38 +00:00
|
|
|
isDraggable = false,
|
|
|
|
|
onPositionChange = onPositionChangeFn,
|
2021-03-29 15:47:22 +00:00
|
|
|
position,
|
2021-07-20 05:18:58 +00:00
|
|
|
renderDragBlock,
|
|
|
|
|
renderDragBlockPositions,
|
2023-10-11 07:14:38 +00:00
|
|
|
themeMode = props.themeMode || ThemeMode.LIGHT,
|
2021-03-29 15:47:22 +00:00
|
|
|
} = props;
|
2023-02-09 11:09:54 +00:00
|
|
|
|
2021-10-20 12:21:07 +00:00
|
|
|
// Memoizing to avoid rerender of draggable icon.
|
2021-06-01 12:07:16 +00:00
|
|
|
// What is the cost of memoizing?
|
|
|
|
|
const popperTheme = useMemo(
|
|
|
|
|
() => getThemeDetails({} as AppState, themeMode),
|
|
|
|
|
[themeMode],
|
2021-03-29 15:47:22 +00:00
|
|
|
);
|
2021-06-01 12:07:16 +00:00
|
|
|
|
2023-02-09 11:09:54 +00:00
|
|
|
const PopperDragHandle = (props: PopperDragHandleProps) => {
|
|
|
|
|
return (
|
|
|
|
|
<DragHandleBlock
|
|
|
|
|
className="drag-handle-block"
|
|
|
|
|
onMouseEnter={(e) => {
|
|
|
|
|
e.stopPropagation();
|
|
|
|
|
if (props?.dragFn) {
|
|
|
|
|
props.dragFn(true);
|
|
|
|
|
}
|
|
|
|
|
}}
|
|
|
|
|
onMouseLeave={(e) => {
|
|
|
|
|
e.stopPropagation();
|
|
|
|
|
if (props?.dragFn) {
|
|
|
|
|
props.dragFn(false);
|
|
|
|
|
}
|
|
|
|
|
}}
|
|
|
|
|
>
|
2023-05-19 18:37:06 +00:00
|
|
|
<Icon name="drag-handle" size="lg" />
|
2023-02-09 11:09:54 +00:00
|
|
|
</DragHandleBlock>
|
|
|
|
|
);
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-21 11:40:24 +00:00
|
|
|
useEffect(() => {
|
2023-02-09 11:09:54 +00:00
|
|
|
const parentElement =
|
|
|
|
|
props?.customParent ||
|
|
|
|
|
(props?.targetNode && props.targetNode?.parentElement);
|
2022-02-18 12:26:09 +00:00
|
|
|
|
2019-12-27 10:10:04 +00:00
|
|
|
if (
|
|
|
|
|
parentElement &&
|
|
|
|
|
parentElement.parentElement &&
|
2020-01-02 12:42:02 +00:00
|
|
|
props.targetNode &&
|
2019-12-27 10:10:04 +00:00
|
|
|
props.isOpen
|
|
|
|
|
) {
|
2020-01-08 04:11:23 +00:00
|
|
|
// TODO: To further optimize this, we can go through the popper API
|
|
|
|
|
// and figure out a way to keep an app instance level popper instance
|
|
|
|
|
// which we can update to have different references when called here.
|
|
|
|
|
// However, the performance benefit gained by such an optimization
|
2021-10-20 12:21:07 +00:00
|
|
|
// remains to be discovered.
|
2020-01-07 12:28:58 +00:00
|
|
|
const _popper = new PopperJS(
|
2020-01-02 12:42:02 +00:00
|
|
|
props.targetNode,
|
chore: upgrade to prettier v2 + enforce import types (#21013)Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
## Description
This PR upgrades Prettier to v2 + enforces TypeScript’s [`import
type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export)
syntax where applicable. It’s submitted as a separate PR so we can merge
it easily.
As a part of this PR, we reformat the codebase heavily:
- add `import type` everywhere where it’s required, and
- re-format the code to account for Prettier 2’s breaking changes:
https://prettier.io/blog/2020/03/21/2.0.0.html#breaking-changes
This PR is submitted against `release` to make sure all new code by team
members will adhere to new formatting standards, and we’ll have fewer
conflicts when merging `bundle-optimizations` into `release`. (I’ll
merge `release` back into `bundle-optimizations` once this PR is
merged.)
### Why is this needed?
This PR is needed because, for the Lodash optimization from
https://github.com/appsmithorg/appsmith/commit/7cbb12af886621256224be0c93e6a465dd710ad3,
we need to use `import type`. Otherwise, `babel-plugin-lodash` complains
that `LoDashStatic` is not a lodash function.
However, just using `import type` in the current codebase will give you
this:
<img width="962" alt="Screenshot 2023-03-08 at 17 45 59"
src="https://user-images.githubusercontent.com/2953267/223775744-407afa0c-e8b9-44a1-90f9-b879348da57f.png">
That’s because Prettier 1 can’t parse `import type` at all. To parse it,
we need to upgrade to Prettier 2.
### Why enforce `import type`?
Apart from just enabling `import type` support, this PR enforces
specifying `import type` everywhere it’s needed. (Developers will get
immediate TypeScript and ESLint errors when they forget to do so.)
I’m doing this because I believe `import type` improves DX and makes
refactorings easier.
Let’s say you had a few imports like below. Can you tell which of these
imports will increase the bundle size? (Tip: it’s not all of them!)
```ts
// app/client/src/workers/Linting/utils.ts
import { Position } from "codemirror";
import { LintError as JSHintError, LintOptions } from "jshint";
import { get, isEmpty, isNumber, keys, last, set } from "lodash";
```
It’s pretty hard, right?
What about now?
```ts
// app/client/src/workers/Linting/utils.ts
import type { Position } from "codemirror";
import type { LintError as JSHintError, LintOptions } from "jshint";
import { get, isEmpty, isNumber, keys, last, set } from "lodash";
```
Now, it’s clear that only `lodash` will be bundled.
This helps developers to see which imports are problematic, but it
_also_ helps with refactorings. Now, if you want to see where
`codemirror` is bundled, you can just grep for `import \{.*\} from
"codemirror"` – and you won’t get any type-only imports.
This also helps (some) bundlers. Upon transpiling, TypeScript erases
type-only imports completely. In some environment (not ours), this makes
the bundle smaller, as the bundler doesn’t need to bundle type-only
imports anymore.
## Type of change
- Chore (housekeeping or task changes that don't impact user perception)
## How Has This Been Tested?
This was tested to not break the build.
### Test Plan
> Add Testsmith test cases links that relate to this PR
### Issues raised during DP testing
> Link issues raised during DP testing for better visiblity and tracking
(copy link from comments dropped on this PR)
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
---------
Co-authored-by: Satish Gandham <hello@satishgandham.com>
Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
2023-03-16 11:41:47 +00:00
|
|
|
contentRef.current as unknown as Element,
|
Property Pane Controls
- Fixes #121, #122, #123, #124, #90, #46, #65, #100, #101, #68, #102
2019-10-24 05:24:45 +00:00
|
|
|
{
|
2021-03-29 15:47:22 +00:00
|
|
|
...(isDraggable && disablePopperEvents
|
|
|
|
|
? {}
|
|
|
|
|
: { placement: props.placement }),
|
|
|
|
|
onCreate: (popperData) => {
|
|
|
|
|
const elementRef: any = popperData.instance.popper;
|
|
|
|
|
if (isDraggable && position) {
|
|
|
|
|
const initPositon =
|
|
|
|
|
position || elementRef.getBoundingClientRect();
|
|
|
|
|
elementRef.style.transform = "unset";
|
|
|
|
|
elementRef.style.top = initPositon.top + "px";
|
|
|
|
|
elementRef.style.left = initPositon.left + "px";
|
|
|
|
|
}
|
|
|
|
|
},
|
Property Pane Controls
- Fixes #121, #122, #123, #124, #90, #46, #65, #100, #101, #68, #102
2019-10-24 05:24:45 +00:00
|
|
|
modifiers: {
|
|
|
|
|
keepTogether: {
|
|
|
|
|
enabled: false,
|
|
|
|
|
},
|
|
|
|
|
arrow: {
|
|
|
|
|
enabled: false,
|
|
|
|
|
},
|
2020-01-15 04:49:36 +00:00
|
|
|
preventOverflow: {
|
|
|
|
|
enabled: true,
|
2022-08-24 12:16:32 +00:00
|
|
|
/*
|
|
|
|
|
Prevent the FilterPane from overflowing the canvas when the
|
2022-02-18 12:26:09 +00:00
|
|
|
table widget is on the very top of the canvas.
|
|
|
|
|
*/
|
|
|
|
|
boundariesElement: boundaryParent,
|
2020-01-15 04:49:36 +00:00
|
|
|
},
|
2020-06-04 13:49:22 +00:00
|
|
|
...props.modifiers,
|
2019-10-21 11:40:24 +00:00
|
|
|
},
|
|
|
|
|
},
|
Property Pane Controls
- Fixes #121, #122, #123, #124, #90, #46, #65, #100, #101, #68, #102
2019-10-24 05:24:45 +00:00
|
|
|
);
|
2021-03-29 15:47:22 +00:00
|
|
|
if (isDraggable) {
|
|
|
|
|
disablePopperEvents && _popper.disableEventListeners();
|
|
|
|
|
draggableElement(
|
2021-09-13 12:35:05 +00:00
|
|
|
`${popperId}-popper`,
|
2021-03-29 15:47:22 +00:00
|
|
|
_popper.popper,
|
|
|
|
|
onPositionChange,
|
2022-02-18 12:26:09 +00:00
|
|
|
parentElement,
|
2021-03-29 15:47:22 +00:00
|
|
|
position,
|
2021-07-20 05:18:58 +00:00
|
|
|
renderDragBlockPositions,
|
|
|
|
|
() =>
|
|
|
|
|
!!renderDragBlock ? (
|
|
|
|
|
renderDragBlock
|
|
|
|
|
) : (
|
|
|
|
|
<ThemeProvider theme={popperTheme}>
|
2023-02-09 11:09:54 +00:00
|
|
|
<PopperDragHandle dragFn={props.setIsDragging} />
|
2021-07-20 05:18:58 +00:00
|
|
|
</ThemeProvider>
|
|
|
|
|
),
|
2021-09-13 12:35:05 +00:00
|
|
|
cypressSelectorDragHandle,
|
2021-03-29 15:47:22 +00:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-07 12:28:58 +00:00
|
|
|
return () => {
|
|
|
|
|
_popper.destroy();
|
|
|
|
|
};
|
Property Pane Controls
- Fixes #121, #122, #123, #124, #90, #46, #65, #100, #101, #68, #102
2019-10-24 05:24:45 +00:00
|
|
|
}
|
2021-03-29 15:47:22 +00:00
|
|
|
}, [
|
|
|
|
|
props.targetNode,
|
|
|
|
|
props.isOpen,
|
2021-06-01 12:07:16 +00:00
|
|
|
JSON.stringify(props.modifiers),
|
2021-03-29 15:47:22 +00:00
|
|
|
props.placement,
|
|
|
|
|
disablePopperEvents,
|
|
|
|
|
]);
|
2019-10-21 11:40:24 +00:00
|
|
|
return createPortal(
|
2021-07-26 05:50:46 +00:00
|
|
|
props.isOpen && (
|
2022-10-14 04:53:31 +00:00
|
|
|
<PopperWrapper
|
|
|
|
|
borderRadius={props.borderRadius}
|
|
|
|
|
ref={contentRef}
|
2023-03-04 07:25:54 +00:00
|
|
|
style={props.style || {}}
|
2022-10-14 04:53:31 +00:00
|
|
|
zIndex={props.zIndex}
|
|
|
|
|
>
|
2021-07-26 05:50:46 +00:00
|
|
|
{props.children}
|
|
|
|
|
</PopperWrapper>
|
|
|
|
|
),
|
2022-10-14 04:53:31 +00:00
|
|
|
props.portalContainer ? props.portalContainer : document.body,
|
2019-10-21 11:40:24 +00:00
|
|
|
);
|
|
|
|
|
};
|