2023-07-05 13:34:03 +00:00
|
|
|
|
import type { ActionPattern, CallEffect, ForkEffect } from "redux-saga/effects";
|
2021-01-04 10:16:08 +00:00
|
|
|
|
import {
|
|
|
|
|
|
actionChannel,
|
2021-12-23 14:17:20 +00:00
|
|
|
|
all,
|
2021-01-04 10:16:08 +00:00
|
|
|
|
call,
|
2022-01-28 11:10:05 +00:00
|
|
|
|
delay,
|
2021-01-04 10:16:08 +00:00
|
|
|
|
fork,
|
|
|
|
|
|
put,
|
|
|
|
|
|
select,
|
2021-12-23 14:17:20 +00:00
|
|
|
|
spawn,
|
2021-01-04 10:16:08 +00:00
|
|
|
|
take,
|
|
|
|
|
|
} from "redux-saga/effects";
|
2020-12-28 08:42:43 +00:00
|
|
|
|
|
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 {
|
2020-11-03 10:16:11 +00:00
|
|
|
|
EvaluationReduxAction,
|
2020-10-21 04:25:32 +00:00
|
|
|
|
ReduxAction,
|
2021-11-10 07:11:23 +00:00
|
|
|
|
ReduxActionType,
|
2023-04-14 09:10:03 +00:00
|
|
|
|
AnyReduxAction,
|
2022-04-12 10:50:01 +00:00
|
|
|
|
} from "@appsmith/constants/ReduxActionConstants";
|
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 { ReduxActionTypes } from "@appsmith/constants/ReduxActionConstants";
|
2021-07-20 05:04:12 +00:00
|
|
|
|
import {
|
|
|
|
|
|
getDataTree,
|
|
|
|
|
|
getUnevaluatedDataTree,
|
|
|
|
|
|
} from "selectors/dataTreeSelectors";
|
2023-02-14 16:07:31 +00:00
|
|
|
|
import { getMetaWidgets, getWidgets } from "sagas/selectors";
|
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 { WidgetTypeConfigMap } from "utils/WidgetFactory";
|
|
|
|
|
|
import WidgetFactory from "utils/WidgetFactory";
|
2021-02-22 05:00:16 +00:00
|
|
|
|
import { GracefulWorkerService } from "utils/WorkerUtil";
|
2023-05-31 06:44:07 +00:00
|
|
|
|
import type { EvalError, EvaluationError } from "utils/DynamicBindingUtils";
|
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 { PropertyEvaluationErrorType } from "utils/DynamicBindingUtils";
|
2023-01-16 11:56:18 +00:00
|
|
|
|
import { EVAL_WORKER_ACTIONS } from "@appsmith/workers/Evaluation/evalWorkerActions";
|
2020-10-21 04:25:32 +00:00
|
|
|
|
import log from "loglevel";
|
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 { WidgetProps } from "widgets/BaseWidget";
|
2020-11-03 10:16:11 +00:00
|
|
|
|
import PerformanceTracker, {
|
|
|
|
|
|
PerformanceTransactionName,
|
2022-04-12 10:50:01 +00:00
|
|
|
|
} from "utils/PerformanceTracker";
|
2020-11-11 11:32:14 +00:00
|
|
|
|
import * as Sentry from "@sentry/react";
|
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 { Action } from "redux";
|
2021-06-04 07:09:36 +00:00
|
|
|
|
import {
|
2023-07-05 13:34:03 +00:00
|
|
|
|
EVAL_AND_LINT_REDUX_ACTIONS,
|
2021-07-20 10:02:56 +00:00
|
|
|
|
FIRST_EVAL_REDUX_ACTIONS,
|
|
|
|
|
|
setDependencyMap,
|
|
|
|
|
|
setEvaluatedTree,
|
2023-07-05 13:34:03 +00:00
|
|
|
|
shouldForceEval,
|
2023-03-24 10:15:11 +00:00
|
|
|
|
shouldLog,
|
2023-07-05 13:34:03 +00:00
|
|
|
|
shouldProcessAction,
|
|
|
|
|
|
shouldTriggerEvaluation,
|
|
|
|
|
|
shouldTriggerLinting,
|
2021-07-20 10:02:56 +00:00
|
|
|
|
} from "actions/evaluationActions";
|
2023-03-20 11:04:02 +00:00
|
|
|
|
import ConfigTreeActions from "utils/configTree";
|
2021-03-13 14:24:45 +00:00
|
|
|
|
import {
|
2023-05-31 06:44:07 +00:00
|
|
|
|
dynamicTriggerErrorHandler,
|
2021-07-20 10:02:56 +00:00
|
|
|
|
evalErrorHandler,
|
2022-06-30 07:21:20 +00:00
|
|
|
|
handleJSFunctionExecutionErrorLog,
|
2023-06-23 10:42:27 +00:00
|
|
|
|
logJSVarCreatedEvent,
|
2021-07-20 10:02:56 +00:00
|
|
|
|
logSuccessfulBindings,
|
|
|
|
|
|
postEvalActionDispatcher,
|
|
|
|
|
|
updateTernDefinitions,
|
|
|
|
|
|
} from "./PostEvaluationSagas";
|
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 { JSAction } from "entities/JSCollection";
|
2023-03-29 17:07:06 +00:00
|
|
|
|
import { getAppMode } from "@appsmith/selectors/applicationSelectors";
|
2021-08-06 09:17:56 +00:00
|
|
|
|
import { APP_MODE } from "entities/App";
|
2023-06-30 10:21:08 +00:00
|
|
|
|
import { get, isEmpty } from "lodash";
|
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 { TriggerMeta } from "@appsmith/sagas/ActionExecution/ActionExecutionSagas";
|
|
|
|
|
|
import { executeActionTriggers } from "@appsmith/sagas/ActionExecution/ActionExecutionSagas";
|
2023-06-09 05:41:07 +00:00
|
|
|
|
import {
|
|
|
|
|
|
EventType,
|
|
|
|
|
|
TriggerKind,
|
|
|
|
|
|
} from "constants/AppsmithActionConstants/ActionConstants";
|
2022-11-03 09:23:15 +00:00
|
|
|
|
import { validate } from "workers/Evaluation/validations";
|
2021-08-24 12:10:25 +00:00
|
|
|
|
import { diff } from "deep-diff";
|
2021-12-07 09:45:18 +00:00
|
|
|
|
import { REPLAY_DELAY } from "entities/Replay/replayUtils";
|
2023-03-29 17:07:06 +00:00
|
|
|
|
import type { EvaluationVersion } from "@appsmith/api/ApplicationApi";
|
2023-04-14 09:10:03 +00:00
|
|
|
|
|
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 { LogObject } from "entities/AppsmithConsole";
|
|
|
|
|
|
import { ENTITY_TYPE } from "entities/AppsmithConsole";
|
|
|
|
|
|
import type { Replayable } from "entities/Replay/ReplayEntity/ReplayEditor";
|
|
|
|
|
|
import type { FormEvaluationState } from "reducers/evaluationReducers/formEvaluationReducer";
|
|
|
|
|
|
import type { FormEvalActionPayload } from "./FormEvaluationSaga";
|
2022-05-04 09:45:57 +00:00
|
|
|
|
import { getSelectedAppTheme } from "selectors/appThemingSelectors";
|
2023-01-13 18:29:03 +00:00
|
|
|
|
import { resetWidgetsMetaState, updateMetaState } from "actions/metaActions";
|
2023-01-17 07:12:16 +00:00
|
|
|
|
import {
|
|
|
|
|
|
getAllActionValidationConfig,
|
|
|
|
|
|
getAllJSActionsData,
|
|
|
|
|
|
} from "selectors/entitiesSelector";
|
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 {
|
2022-12-02 12:45:11 +00:00
|
|
|
|
DataTree,
|
2023-04-07 07:41:36 +00:00
|
|
|
|
UnEvalTree,
|
2023-03-20 11:04:02 +00:00
|
|
|
|
WidgetEntityConfig,
|
2022-12-02 12:45:11 +00:00
|
|
|
|
} from "entities/DataTree/dataTreeFactory";
|
2023-04-07 07:41:36 +00:00
|
|
|
|
|
2023-07-05 13:34:03 +00:00
|
|
|
|
import { initiateLinting, lintWorker } from "./LintingSagas";
|
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 {
|
2022-11-03 09:23:15 +00:00
|
|
|
|
EvalTreeRequestData,
|
|
|
|
|
|
EvalTreeResponseData,
|
|
|
|
|
|
} from "workers/Evaluation/types";
|
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 { ActionDescription } from "@appsmith/workers/Evaluation/fns";
|
2023-01-16 11:56:18 +00:00
|
|
|
|
import { handleEvalWorkerRequestSaga } from "./EvalWorkerActionSagas";
|
2023-04-26 07:18:16 +00:00
|
|
|
|
import { getAppsmithConfigs } from "@appsmith/configs";
|
2023-04-14 09:10:03 +00:00
|
|
|
|
import { executeJSUpdates } from "actions/pluginActionActions";
|
2023-05-16 16:59:11 +00:00
|
|
|
|
import { setEvaluatedActionSelectorField } from "actions/actionSelectorActions";
|
2023-07-10 05:51:40 +00:00
|
|
|
|
import { waitForWidgetConfigBuild } from "./InitSagas";
|
2023-02-20 11:56:40 +00:00
|
|
|
|
|
|
|
|
|
|
const APPSMITH_CONFIGS = getAppsmithConfigs();
|
2021-11-10 07:11:23 +00:00
|
|
|
|
|
2023-01-16 11:56:18 +00:00
|
|
|
|
export const evalWorker = new GracefulWorkerService(
|
2022-11-03 09:23:15 +00:00
|
|
|
|
new Worker(
|
|
|
|
|
|
new URL("../workers/Evaluation/evaluation.worker.ts", import.meta.url),
|
|
|
|
|
|
{
|
|
|
|
|
|
type: "module",
|
2023-07-05 13:34:03 +00:00
|
|
|
|
// Note: the `Worker` part of the name is slightly important – LinkRelPreload_spec.js
|
|
|
|
|
|
// relies on it to find workers in the list of all requests.
|
2022-11-03 09:23:15 +00:00
|
|
|
|
name: "evalWorker",
|
|
|
|
|
|
},
|
|
|
|
|
|
),
|
|
|
|
|
|
);
|
2020-10-21 04:25:32 +00:00
|
|
|
|
|
2022-11-03 09:23:15 +00:00
|
|
|
|
let widgetTypeConfigMap: WidgetTypeConfigMap;
|
2022-06-24 11:59:30 +00:00
|
|
|
|
|
2023-04-07 07:41:36 +00:00
|
|
|
|
export function* updateDataTreeHandler(
|
|
|
|
|
|
data: {
|
|
|
|
|
|
evalTreeResponse: EvalTreeResponseData;
|
|
|
|
|
|
unevalTree: UnEvalTree;
|
|
|
|
|
|
requiresLogging: boolean;
|
|
|
|
|
|
},
|
2022-02-17 04:31:59 +00:00
|
|
|
|
postEvalActions?: Array<AnyReduxAction>,
|
2021-04-26 05:41:32 +00:00
|
|
|
|
) {
|
2023-04-07 07:41:36 +00:00
|
|
|
|
const { evalTreeResponse, requiresLogging, unevalTree } = data;
|
2023-04-14 09:10:03 +00:00
|
|
|
|
const postEvalActionsToDispatch: Array<AnyReduxAction> =
|
|
|
|
|
|
postEvalActions || [];
|
2022-01-27 09:50:05 +00:00
|
|
|
|
|
2021-06-04 07:09:36 +00:00
|
|
|
|
const {
|
2023-05-31 06:44:07 +00:00
|
|
|
|
configTree,
|
2021-06-04 07:09:36 +00:00
|
|
|
|
dataTree,
|
|
|
|
|
|
dependencies,
|
|
|
|
|
|
errors,
|
2022-06-07 06:36:27 +00:00
|
|
|
|
evalMetaUpdates = [],
|
2021-06-04 07:09:36 +00:00
|
|
|
|
evaluationOrder,
|
2023-07-21 11:11:50 +00:00
|
|
|
|
reValidatedPaths,
|
2023-05-31 06:44:07 +00:00
|
|
|
|
isCreateFirstTree = false,
|
|
|
|
|
|
isNewWidgetAdded,
|
2021-11-08 06:49:22 +00:00
|
|
|
|
jsUpdates,
|
2021-06-04 07:09:36 +00:00
|
|
|
|
logs,
|
2023-02-21 04:27:56 +00:00
|
|
|
|
pathsToClearErrorsFor,
|
2023-05-31 06:44:07 +00:00
|
|
|
|
staleMetaIds,
|
2023-05-16 10:46:40 +00:00
|
|
|
|
undefinedEvalValuesMap,
|
2023-05-31 06:44:07 +00:00
|
|
|
|
unEvalUpdates,
|
2023-06-23 10:42:27 +00:00
|
|
|
|
jsVarsCreatedEvent,
|
2023-04-07 07:41:36 +00:00
|
|
|
|
} = evalTreeResponse;
|
|
|
|
|
|
|
|
|
|
|
|
const appMode: ReturnType<typeof getAppMode> = yield select(getAppMode);
|
2023-02-21 04:27:56 +00:00
|
|
|
|
|
2021-03-31 07:40:59 +00:00
|
|
|
|
PerformanceTracker.stopAsyncTracking(
|
|
|
|
|
|
PerformanceTransactionName.DATA_TREE_EVALUATION,
|
|
|
|
|
|
);
|
|
|
|
|
|
PerformanceTracker.startAsyncTracking(
|
|
|
|
|
|
PerformanceTransactionName.SET_EVALUATED_TREE,
|
|
|
|
|
|
);
|
2023-04-07 07:41:36 +00:00
|
|
|
|
const oldDataTree: ReturnType<typeof getDataTree> = yield select(getDataTree);
|
2021-08-24 12:10:25 +00:00
|
|
|
|
|
|
|
|
|
|
const updates = diff(oldDataTree, dataTree) || [];
|
2023-02-14 16:07:31 +00:00
|
|
|
|
|
|
|
|
|
|
if (!isEmpty(staleMetaIds)) {
|
|
|
|
|
|
yield put(resetWidgetsMetaState(staleMetaIds));
|
2023-01-13 18:29:03 +00:00
|
|
|
|
}
|
2022-05-25 09:46:14 +00:00
|
|
|
|
yield put(setEvaluatedTree(updates));
|
2023-03-20 11:04:02 +00:00
|
|
|
|
ConfigTreeActions.setConfigTree(configTree);
|
|
|
|
|
|
|
2021-04-23 11:34:33 +00:00
|
|
|
|
PerformanceTracker.stopAsyncTracking(
|
2021-03-31 07:40:59 +00:00
|
|
|
|
PerformanceTransactionName.SET_EVALUATED_TREE,
|
|
|
|
|
|
);
|
2023-03-20 11:04:02 +00:00
|
|
|
|
|
2022-05-25 09:46:14 +00:00
|
|
|
|
// if evalMetaUpdates are present only then dispatch updateMetaState
|
|
|
|
|
|
if (evalMetaUpdates.length) {
|
|
|
|
|
|
yield put(updateMetaState(evalMetaUpdates));
|
|
|
|
|
|
}
|
2022-06-25 05:30:54 +00:00
|
|
|
|
log.debug({ evalMetaUpdatesLength: evalMetaUpdates.length });
|
2021-07-20 05:04:12 +00:00
|
|
|
|
|
2022-05-25 09:46:14 +00:00
|
|
|
|
const updatedDataTree: DataTree = yield select(getDataTree);
|
2023-03-20 11:04:02 +00:00
|
|
|
|
|
2021-11-08 06:49:22 +00:00
|
|
|
|
log.debug({ jsUpdates: jsUpdates });
|
2021-07-20 05:04:12 +00:00
|
|
|
|
log.debug({ dataTree: updatedDataTree });
|
2021-12-03 06:48:37 +00:00
|
|
|
|
logs?.forEach((evalLog: any) => log.debug(evalLog));
|
2023-07-21 11:11:50 +00:00
|
|
|
|
|
2023-02-21 04:27:56 +00:00
|
|
|
|
yield call(
|
2023-07-21 11:11:50 +00:00
|
|
|
|
evalErrorHandler,
|
2023-02-21 04:27:56 +00:00
|
|
|
|
errors,
|
|
|
|
|
|
updatedDataTree,
|
|
|
|
|
|
evaluationOrder,
|
2023-07-21 11:11:50 +00:00
|
|
|
|
reValidatedPaths,
|
2023-03-20 11:04:02 +00:00
|
|
|
|
configTree,
|
2023-02-21 04:27:56 +00:00
|
|
|
|
pathsToClearErrorsFor,
|
|
|
|
|
|
);
|
2022-05-25 09:46:14 +00:00
|
|
|
|
|
2021-07-30 10:24:22 +00:00
|
|
|
|
if (appMode !== APP_MODE.PUBLISHED) {
|
2023-01-17 07:12:16 +00:00
|
|
|
|
const jsData: Record<string, unknown> = yield select(getAllJSActionsData);
|
2023-04-14 09:10:03 +00:00
|
|
|
|
postEvalActionsToDispatch.push(executeJSUpdates(jsUpdates));
|
2023-03-24 10:15:11 +00:00
|
|
|
|
|
|
|
|
|
|
if (requiresLogging) {
|
|
|
|
|
|
yield fork(
|
|
|
|
|
|
logSuccessfulBindings,
|
|
|
|
|
|
unevalTree,
|
|
|
|
|
|
updatedDataTree,
|
|
|
|
|
|
evaluationOrder,
|
|
|
|
|
|
isCreateFirstTree,
|
|
|
|
|
|
isNewWidgetAdded,
|
|
|
|
|
|
configTree,
|
2023-05-16 10:46:40 +00:00
|
|
|
|
undefinedEvalValuesMap,
|
2023-03-24 10:15:11 +00:00
|
|
|
|
);
|
|
|
|
|
|
}
|
2021-07-30 10:24:22 +00:00
|
|
|
|
|
2022-11-27 06:11:01 +00:00
|
|
|
|
yield fork(
|
|
|
|
|
|
updateTernDefinitions,
|
|
|
|
|
|
updatedDataTree,
|
2023-03-20 11:04:02 +00:00
|
|
|
|
configTree,
|
2022-11-27 06:11:01 +00:00
|
|
|
|
unEvalUpdates,
|
|
|
|
|
|
isCreateFirstTree,
|
2023-01-17 07:12:16 +00:00
|
|
|
|
jsData,
|
2022-11-27 06:11:01 +00:00
|
|
|
|
);
|
2021-07-30 10:24:22 +00:00
|
|
|
|
}
|
2021-07-20 10:02:56 +00:00
|
|
|
|
yield put(setDependencyMap(dependencies));
|
2023-04-14 09:10:03 +00:00
|
|
|
|
if (postEvalActionsToDispatch && postEvalActionsToDispatch.length) {
|
|
|
|
|
|
yield call(postEvalActionDispatcher, postEvalActionsToDispatch);
|
2020-11-03 10:16:11 +00:00
|
|
|
|
}
|
2023-06-23 10:42:27 +00:00
|
|
|
|
|
|
|
|
|
|
yield call(logJSVarCreatedEvent, jsVarsCreatedEvent);
|
2020-10-21 04:25:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2023-04-07 07:41:36 +00:00
|
|
|
|
/**
|
|
|
|
|
|
* This saga is responsible for evaluating the data tree
|
|
|
|
|
|
* @param postEvalActions
|
|
|
|
|
|
* @param shouldReplay
|
|
|
|
|
|
* @param requiresLinting
|
|
|
|
|
|
* @param forceEvaluation - if true, will re-evaluate the entire tree
|
|
|
|
|
|
* @returns
|
|
|
|
|
|
* @example
|
|
|
|
|
|
* yield call(evaluateTreeSaga, postEvalActions, shouldReplay, requiresLinting, forceEvaluation)
|
|
|
|
|
|
*/
|
|
|
|
|
|
export function* evaluateTreeSaga(
|
2023-07-05 13:34:03 +00:00
|
|
|
|
unEvalAndConfigTree: ReturnType<typeof getUnevaluatedDataTree>,
|
2023-04-07 07:41:36 +00:00
|
|
|
|
postEvalActions?: Array<AnyReduxAction>,
|
|
|
|
|
|
shouldReplay = true,
|
|
|
|
|
|
forceEvaluation = false,
|
|
|
|
|
|
requiresLogging = false,
|
|
|
|
|
|
) {
|
|
|
|
|
|
const allActionValidationConfig: ReturnType<
|
|
|
|
|
|
typeof getAllActionValidationConfig
|
|
|
|
|
|
> = yield select(getAllActionValidationConfig);
|
|
|
|
|
|
const unevalTree = unEvalAndConfigTree.unEvalTree;
|
|
|
|
|
|
const widgets: ReturnType<typeof getWidgets> = yield select(getWidgets);
|
|
|
|
|
|
const metaWidgets: ReturnType<typeof getMetaWidgets> = yield select(
|
|
|
|
|
|
getMetaWidgets,
|
|
|
|
|
|
);
|
|
|
|
|
|
const theme: ReturnType<typeof getSelectedAppTheme> = yield select(
|
|
|
|
|
|
getSelectedAppTheme,
|
|
|
|
|
|
);
|
|
|
|
|
|
const appMode: ReturnType<typeof getAppMode> = yield select(getAppMode);
|
|
|
|
|
|
const toPrintConfigTree = unEvalAndConfigTree.configTree;
|
|
|
|
|
|
log.debug({ unevalTree, configTree: toPrintConfigTree });
|
|
|
|
|
|
PerformanceTracker.startAsyncTracking(
|
|
|
|
|
|
PerformanceTransactionName.DATA_TREE_EVALUATION,
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
const evalTreeRequestData: EvalTreeRequestData = {
|
|
|
|
|
|
unevalTree: unEvalAndConfigTree,
|
|
|
|
|
|
widgetTypeConfigMap,
|
|
|
|
|
|
widgets,
|
|
|
|
|
|
theme,
|
|
|
|
|
|
shouldReplay,
|
|
|
|
|
|
allActionValidationConfig,
|
|
|
|
|
|
forceEvaluation,
|
|
|
|
|
|
metaWidgets,
|
|
|
|
|
|
appMode,
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
const workerResponse: EvalTreeResponseData = yield call(
|
|
|
|
|
|
evalWorker.request,
|
|
|
|
|
|
EVAL_WORKER_ACTIONS.EVAL_TREE,
|
|
|
|
|
|
evalTreeRequestData,
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
yield call(
|
|
|
|
|
|
updateDataTreeHandler,
|
|
|
|
|
|
{ evalTreeResponse: workerResponse, unevalTree, requiresLogging },
|
|
|
|
|
|
postEvalActions,
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-01-14 14:37:21 +00:00
|
|
|
|
export function* evaluateActionBindings(
|
|
|
|
|
|
bindings: string[],
|
|
|
|
|
|
executionParams: Record<string, any> | string = {},
|
2020-12-14 18:48:13 +00:00
|
|
|
|
) {
|
2022-06-21 13:57:34 +00:00
|
|
|
|
const workerResponse: { errors: EvalError[]; values: unknown } = yield call(
|
2022-11-03 09:23:15 +00:00
|
|
|
|
evalWorker.request,
|
2021-01-14 14:37:21 +00:00
|
|
|
|
EVAL_WORKER_ACTIONS.EVAL_ACTION_BINDINGS,
|
2020-12-28 08:42:43 +00:00
|
|
|
|
{
|
2021-01-14 14:37:21 +00:00
|
|
|
|
bindings,
|
|
|
|
|
|
executionParams,
|
2020-12-28 08:42:43 +00:00
|
|
|
|
},
|
|
|
|
|
|
);
|
|
|
|
|
|
|
2021-01-14 14:37:21 +00:00
|
|
|
|
const { errors, values } = workerResponse;
|
2020-12-28 08:42:43 +00:00
|
|
|
|
|
2021-06-04 07:09:36 +00:00
|
|
|
|
yield call(evalErrorHandler, errors);
|
2021-01-14 14:37:21 +00:00
|
|
|
|
return values;
|
2020-10-21 04:25:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-12-23 14:17:20 +00:00
|
|
|
|
export function* evaluateAndExecuteDynamicTrigger(
|
2020-10-21 04:25:32 +00:00
|
|
|
|
dynamicTrigger: string,
|
2021-12-23 14:17:20 +00:00
|
|
|
|
eventType: EventType,
|
|
|
|
|
|
triggerMeta: TriggerMeta,
|
2020-11-20 09:30:50 +00:00
|
|
|
|
callbackData?: Array<any>,
|
2022-03-02 06:37:20 +00:00
|
|
|
|
globalContext?: Record<string, unknown>,
|
2020-10-21 04:25:32 +00:00
|
|
|
|
) {
|
2023-03-20 11:04:02 +00:00
|
|
|
|
const unEvalTree: ReturnType<typeof getUnevaluatedDataTree> = yield select(
|
|
|
|
|
|
getUnevaluatedDataTree,
|
|
|
|
|
|
);
|
2023-07-06 13:20:31 +00:00
|
|
|
|
// const unEvalTree = unEvalAndConfigTree.unEvalTree;
|
2021-12-23 14:17:20 +00:00
|
|
|
|
log.debug({ execute: dynamicTrigger });
|
2023-05-31 06:44:07 +00:00
|
|
|
|
const response: { errors: EvaluationError[]; result: unknown } = yield call(
|
2022-12-21 17:14:47 +00:00
|
|
|
|
evalWorker.request,
|
2020-12-28 08:42:43 +00:00
|
|
|
|
EVAL_WORKER_ACTIONS.EVAL_TRIGGER,
|
2022-09-30 01:31:05 +00:00
|
|
|
|
{
|
2022-12-02 12:45:11 +00:00
|
|
|
|
unEvalTree,
|
2022-09-30 01:31:05 +00:00
|
|
|
|
dynamicTrigger,
|
|
|
|
|
|
callbackData,
|
|
|
|
|
|
globalContext,
|
2022-10-10 06:39:14 +00:00
|
|
|
|
eventType,
|
2022-10-17 17:10:17 +00:00
|
|
|
|
triggerMeta,
|
2022-09-30 01:31:05 +00:00
|
|
|
|
},
|
2020-12-28 08:42:43 +00:00
|
|
|
|
);
|
2023-02-11 18:33:20 +00:00
|
|
|
|
const { errors = [] } = response as any;
|
2023-05-31 06:44:07 +00:00
|
|
|
|
yield call(dynamicTriggerErrorHandler, errors);
|
2022-12-21 17:14:47 +00:00
|
|
|
|
return response;
|
|
|
|
|
|
}
|
2022-09-04 11:58:05 +00:00
|
|
|
|
|
2023-01-16 11:56:18 +00:00
|
|
|
|
export interface ResponsePayload {
|
2021-12-23 14:17:20 +00:00
|
|
|
|
data: {
|
|
|
|
|
|
reason?: string;
|
|
|
|
|
|
resolve?: unknown;
|
|
|
|
|
|
};
|
|
|
|
|
|
success: boolean;
|
|
|
|
|
|
}
|
2021-09-15 05:11:13 +00:00
|
|
|
|
|
2021-12-23 14:17:20 +00:00
|
|
|
|
/*
|
|
|
|
|
|
* It is necessary to respond back as the worker is waiting with a pending promise and wanting to know if it should
|
|
|
|
|
|
* resolve or reject it with the data the execution has provided
|
|
|
|
|
|
*/
|
2023-01-16 11:56:18 +00:00
|
|
|
|
export function* executeTriggerRequestSaga(
|
2022-12-21 17:14:47 +00:00
|
|
|
|
trigger: ActionDescription,
|
2021-12-23 14:17:20 +00:00
|
|
|
|
eventType: EventType,
|
|
|
|
|
|
triggerMeta: TriggerMeta,
|
|
|
|
|
|
) {
|
2023-02-11 18:33:20 +00:00
|
|
|
|
const responsePayload = {
|
|
|
|
|
|
data: null,
|
|
|
|
|
|
error: null,
|
2021-12-23 14:17:20 +00:00
|
|
|
|
};
|
|
|
|
|
|
try {
|
2023-02-11 18:33:20 +00:00
|
|
|
|
responsePayload.data = yield call(
|
2021-12-23 14:17:20 +00:00
|
|
|
|
executeActionTriggers,
|
2022-12-21 17:14:47 +00:00
|
|
|
|
trigger,
|
2021-12-23 14:17:20 +00:00
|
|
|
|
eventType,
|
|
|
|
|
|
triggerMeta,
|
|
|
|
|
|
);
|
2022-06-21 13:57:34 +00:00
|
|
|
|
} catch (error) {
|
2021-12-23 14:17:20 +00:00
|
|
|
|
// When error occurs in execution of triggers,
|
|
|
|
|
|
// a success: false is sent to reject the promise
|
2022-06-21 13:57:34 +00:00
|
|
|
|
// @ts-expect-error: reason is of type string
|
2023-02-11 18:33:20 +00:00
|
|
|
|
responsePayload.error = {
|
|
|
|
|
|
// @ts-expect-error: reason is of type string
|
|
|
|
|
|
message: error.responseData?.[0] || error.message,
|
|
|
|
|
|
};
|
2021-12-23 14:17:20 +00:00
|
|
|
|
}
|
2022-12-21 17:14:47 +00:00
|
|
|
|
return responsePayload;
|
2020-10-21 04:25:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
export function* clearEvalCache() {
|
2023-05-06 14:00:50 +00:00
|
|
|
|
yield put({ type: ReduxActionTypes.RESET_DATA_TREE });
|
2022-11-03 09:23:15 +00:00
|
|
|
|
yield call(evalWorker.request, EVAL_WORKER_ACTIONS.CLEAR_CACHE);
|
2020-12-28 08:42:43 +00:00
|
|
|
|
return true;
|
2020-10-21 04:25:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2023-01-28 13:12:11 +00:00
|
|
|
|
interface JSFunctionExecutionResponse {
|
|
|
|
|
|
errors: unknown[];
|
|
|
|
|
|
result: unknown;
|
|
|
|
|
|
logs?: LogObject[];
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
function* executeAsyncJSFunction(
|
2022-06-30 07:21:20 +00:00
|
|
|
|
collectionName: string,
|
|
|
|
|
|
action: JSAction,
|
|
|
|
|
|
collectionId: string,
|
|
|
|
|
|
) {
|
2021-12-23 14:17:20 +00:00
|
|
|
|
const functionCall = `${collectionName}.${action.name}()`;
|
2023-02-11 18:33:20 +00:00
|
|
|
|
const triggerMeta = {
|
|
|
|
|
|
source: {
|
|
|
|
|
|
id: collectionId,
|
|
|
|
|
|
name: `${collectionName}.${action.name}`,
|
|
|
|
|
|
type: ENTITY_TYPE.JSACTION,
|
|
|
|
|
|
},
|
|
|
|
|
|
triggerPropertyName: `${collectionName}.${action.name}`,
|
2023-06-09 05:41:07 +00:00
|
|
|
|
triggerKind: TriggerKind.JS_FUNCTION_EXECUTION,
|
2023-02-11 18:33:20 +00:00
|
|
|
|
};
|
|
|
|
|
|
const eventType = EventType.ON_JS_FUNCTION_EXECUTE;
|
2023-05-31 06:44:07 +00:00
|
|
|
|
const response: JSFunctionExecutionResponse = yield call(
|
|
|
|
|
|
evaluateAndExecuteDynamicTrigger,
|
|
|
|
|
|
functionCall,
|
|
|
|
|
|
eventType,
|
|
|
|
|
|
triggerMeta,
|
|
|
|
|
|
);
|
2023-01-28 13:12:11 +00:00
|
|
|
|
return response;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
export function* executeJSFunction(
|
|
|
|
|
|
collectionName: string,
|
|
|
|
|
|
action: JSAction,
|
|
|
|
|
|
collectionId: string,
|
|
|
|
|
|
) {
|
2023-05-31 06:44:07 +00:00
|
|
|
|
const response: {
|
2023-01-28 13:12:11 +00:00
|
|
|
|
errors: unknown[];
|
|
|
|
|
|
result: unknown;
|
2022-09-04 11:58:05 +00:00
|
|
|
|
logs?: LogObject[];
|
2023-05-31 06:44:07 +00:00
|
|
|
|
} = yield call(executeAsyncJSFunction, collectionName, action, collectionId);
|
2021-12-23 14:17:20 +00:00
|
|
|
|
const { errors, result } = response;
|
2022-05-11 10:20:33 +00:00
|
|
|
|
const isDirty = !!errors.length;
|
|
|
|
|
|
|
2023-01-28 13:12:11 +00:00
|
|
|
|
// After every function execution, log execution errors if present
|
2022-06-30 07:21:20 +00:00
|
|
|
|
yield call(
|
|
|
|
|
|
handleJSFunctionExecutionErrorLog,
|
|
|
|
|
|
collectionId,
|
|
|
|
|
|
collectionName,
|
|
|
|
|
|
action,
|
|
|
|
|
|
errors,
|
|
|
|
|
|
);
|
2022-05-11 10:20:33 +00:00
|
|
|
|
return { result, isDirty };
|
2021-09-08 17:32:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-10-21 04:25:32 +00:00
|
|
|
|
export function* validateProperty(
|
|
|
|
|
|
property: string,
|
|
|
|
|
|
value: any,
|
|
|
|
|
|
props: WidgetProps,
|
|
|
|
|
|
) {
|
2023-03-20 11:04:02 +00:00
|
|
|
|
const unEvalAndConfigTree: ReturnType<typeof getUnevaluatedDataTree> =
|
|
|
|
|
|
yield select(getUnevaluatedDataTree);
|
|
|
|
|
|
const configTree = unEvalAndConfigTree.configTree;
|
|
|
|
|
|
const entityConfig = configTree[props.widgetName] as WidgetEntityConfig;
|
|
|
|
|
|
const validation = entityConfig?.validationPaths[property];
|
2022-06-21 13:57:34 +00:00
|
|
|
|
const response: unknown = yield call(
|
2022-11-03 09:23:15 +00:00
|
|
|
|
evalWorker.request,
|
2022-06-21 13:57:34 +00:00
|
|
|
|
EVAL_WORKER_ACTIONS.VALIDATE_PROPERTY,
|
|
|
|
|
|
{
|
|
|
|
|
|
property,
|
|
|
|
|
|
value,
|
|
|
|
|
|
props,
|
|
|
|
|
|
validation,
|
|
|
|
|
|
},
|
|
|
|
|
|
);
|
|
|
|
|
|
return response;
|
2020-10-21 04:25:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-12-30 13:26:44 +00:00
|
|
|
|
function evalQueueBuffer() {
|
2021-01-04 10:16:08 +00:00
|
|
|
|
let canTake = false;
|
2022-02-17 04:31:59 +00:00
|
|
|
|
let collectedPostEvalActions: any = [];
|
2020-12-30 13:26:44 +00:00
|
|
|
|
const take = () => {
|
2021-01-04 10:16:08 +00:00
|
|
|
|
if (canTake) {
|
2022-02-17 04:31:59 +00:00
|
|
|
|
const resp = collectedPostEvalActions;
|
|
|
|
|
|
collectedPostEvalActions = [];
|
2021-01-04 10:16:08 +00:00
|
|
|
|
canTake = false;
|
2023-07-05 13:34:03 +00:00
|
|
|
|
return { postEvalActions: resp, type: ReduxActionTypes.BUFFERED_ACTION };
|
2020-12-30 13:26:44 +00:00
|
|
|
|
}
|
|
|
|
|
|
};
|
|
|
|
|
|
const flush = () => {
|
2021-01-04 10:16:08 +00:00
|
|
|
|
if (canTake) {
|
2020-12-30 13:26:44 +00:00
|
|
|
|
return [take() as Action];
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return [];
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
const put = (action: EvaluationReduxAction<unknown | unknown[]>) => {
|
2023-07-05 13:34:03 +00:00
|
|
|
|
if (!shouldProcessAction(action)) {
|
2021-01-14 11:15:25 +00:00
|
|
|
|
return;
|
|
|
|
|
|
}
|
2021-01-04 10:16:08 +00:00
|
|
|
|
canTake = true;
|
2021-01-14 11:15:25 +00:00
|
|
|
|
|
2022-02-17 04:31:59 +00:00
|
|
|
|
const postEvalActions = getPostEvalActions(action);
|
|
|
|
|
|
collectedPostEvalActions.push(...postEvalActions);
|
2020-12-30 13:26:44 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
|
take,
|
|
|
|
|
|
put,
|
|
|
|
|
|
isEmpty: () => {
|
2021-01-04 10:16:08 +00:00
|
|
|
|
return !canTake;
|
2020-12-30 13:26:44 +00:00
|
|
|
|
},
|
|
|
|
|
|
flush,
|
|
|
|
|
|
};
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-02-17 04:31:59 +00:00
|
|
|
|
/**
|
|
|
|
|
|
* Extract the post eval actions from an evaluation action
|
|
|
|
|
|
* Batched actions have post eval actions inside them, extract that
|
|
|
|
|
|
*
|
|
|
|
|
|
* **/
|
|
|
|
|
|
function getPostEvalActions(
|
|
|
|
|
|
action: EvaluationReduxAction<unknown | unknown[]>,
|
|
|
|
|
|
): AnyReduxAction[] {
|
|
|
|
|
|
const postEvalActions: AnyReduxAction[] = [];
|
|
|
|
|
|
if (action.postEvalActions) {
|
|
|
|
|
|
postEvalActions.push(...action.postEvalActions);
|
|
|
|
|
|
}
|
|
|
|
|
|
if (
|
|
|
|
|
|
action.type === ReduxActionTypes.BATCH_UPDATES_SUCCESS &&
|
|
|
|
|
|
Array.isArray(action.payload)
|
|
|
|
|
|
) {
|
|
|
|
|
|
action.payload.forEach((batchedAction) => {
|
|
|
|
|
|
if (batchedAction.postEvalActions) {
|
|
|
|
|
|
postEvalActions.push(
|
|
|
|
|
|
...(batchedAction.postEvalActions as AnyReduxAction[]),
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
});
|
|
|
|
|
|
}
|
|
|
|
|
|
return postEvalActions;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2023-07-05 13:34:03 +00:00
|
|
|
|
function* evalAndLintingHandler(
|
|
|
|
|
|
isBlockingCall = true,
|
|
|
|
|
|
action: ReduxAction<unknown>,
|
|
|
|
|
|
options: Partial<{
|
|
|
|
|
|
shouldReplay: boolean;
|
|
|
|
|
|
forceEvaluation: boolean;
|
|
|
|
|
|
requiresLogging: boolean;
|
|
|
|
|
|
}>,
|
|
|
|
|
|
) {
|
|
|
|
|
|
const { forceEvaluation, requiresLogging, shouldReplay } = options;
|
|
|
|
|
|
const appMode: ReturnType<typeof getAppMode> = yield select(getAppMode);
|
|
|
|
|
|
|
|
|
|
|
|
const requiresLinting =
|
|
|
|
|
|
appMode === APP_MODE.EDIT && shouldTriggerLinting(action);
|
|
|
|
|
|
|
|
|
|
|
|
const requiresEval = shouldTriggerEvaluation(action);
|
|
|
|
|
|
log.debug({
|
|
|
|
|
|
action,
|
|
|
|
|
|
triggeredLinting: requiresLinting,
|
|
|
|
|
|
triggeredEvaluation: requiresEval,
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
if (!requiresEval && !requiresLinting) return;
|
|
|
|
|
|
|
|
|
|
|
|
// Generate all the data needed for both eval and linting
|
|
|
|
|
|
const unEvalAndConfigTree: ReturnType<typeof getUnevaluatedDataTree> =
|
|
|
|
|
|
yield select(getUnevaluatedDataTree);
|
|
|
|
|
|
const postEvalActions = getPostEvalActions(action);
|
|
|
|
|
|
const fn: (...args: unknown[]) => CallEffect<unknown> | ForkEffect<unknown> =
|
|
|
|
|
|
isBlockingCall ? call : fork;
|
|
|
|
|
|
|
|
|
|
|
|
const effects = [];
|
|
|
|
|
|
|
|
|
|
|
|
if (requiresEval) {
|
|
|
|
|
|
effects.push(
|
|
|
|
|
|
fn(
|
|
|
|
|
|
evaluateTreeSaga,
|
|
|
|
|
|
unEvalAndConfigTree,
|
|
|
|
|
|
postEvalActions,
|
|
|
|
|
|
shouldReplay,
|
|
|
|
|
|
forceEvaluation,
|
|
|
|
|
|
requiresLogging,
|
|
|
|
|
|
),
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
if (requiresLinting) {
|
|
|
|
|
|
effects.push(fn(initiateLinting, unEvalAndConfigTree, forceEvaluation));
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
yield all(effects);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-12-21 17:14:47 +00:00
|
|
|
|
function* evaluationChangeListenerSaga(): any {
|
2020-12-30 13:26:44 +00:00
|
|
|
|
// Explicitly shutdown old worker if present
|
2022-11-03 09:23:15 +00:00
|
|
|
|
yield all([call(evalWorker.shutdown), call(lintWorker.shutdown)]);
|
2022-12-21 17:14:47 +00:00
|
|
|
|
const [evalWorkerListenerChannel] = yield all([
|
2022-11-03 09:23:15 +00:00
|
|
|
|
call(evalWorker.start),
|
|
|
|
|
|
call(lintWorker.start),
|
|
|
|
|
|
]);
|
2022-09-30 01:31:05 +00:00
|
|
|
|
|
2023-02-20 11:56:40 +00:00
|
|
|
|
yield call(evalWorker.request, EVAL_WORKER_ACTIONS.SETUP, {
|
|
|
|
|
|
cloudHosting: !!APPSMITH_CONFIGS.cloudHosting,
|
|
|
|
|
|
});
|
2022-12-21 17:14:47 +00:00
|
|
|
|
yield spawn(handleEvalWorkerRequestSaga, evalWorkerListenerChannel);
|
2022-09-30 01:31:05 +00:00
|
|
|
|
|
2023-07-05 13:34:03 +00:00
|
|
|
|
const initAction: EvaluationReduxAction<unknown> = yield take(
|
|
|
|
|
|
FIRST_EVAL_REDUX_ACTIONS,
|
|
|
|
|
|
);
|
2023-07-10 05:51:40 +00:00
|
|
|
|
yield call(waitForWidgetConfigBuild);
|
|
|
|
|
|
widgetTypeConfigMap = WidgetFactory.getWidgetTypeConfigMap();
|
2023-07-05 13:34:03 +00:00
|
|
|
|
yield fork(evalAndLintingHandler, false, initAction, {
|
|
|
|
|
|
shouldReplay: false,
|
|
|
|
|
|
forceEvaluation: false,
|
|
|
|
|
|
});
|
2022-06-21 13:57:34 +00:00
|
|
|
|
const evtActionChannel: ActionPattern<Action<any>> = yield actionChannel(
|
2023-07-05 13:34:03 +00:00
|
|
|
|
EVAL_AND_LINT_REDUX_ACTIONS,
|
2020-12-30 13:26:44 +00:00
|
|
|
|
evalQueueBuffer(),
|
|
|
|
|
|
);
|
|
|
|
|
|
while (true) {
|
|
|
|
|
|
const action: EvaluationReduxAction<unknown | unknown[]> = yield take(
|
|
|
|
|
|
evtActionChannel,
|
|
|
|
|
|
);
|
2022-05-04 09:45:57 +00:00
|
|
|
|
|
2023-07-05 13:34:03 +00:00
|
|
|
|
yield call(evalAndLintingHandler, true, action, {
|
|
|
|
|
|
shouldReplay: get(action, "payload.shouldReplay"),
|
|
|
|
|
|
forceEvaluation: shouldForceEval(action),
|
|
|
|
|
|
requiresLogging: shouldLog(action),
|
|
|
|
|
|
});
|
2020-10-21 04:25:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2023-05-16 16:59:11 +00:00
|
|
|
|
export function* evaluateActionSelectorFieldSaga(action: any) {
|
|
|
|
|
|
const { id, type, value } = action.payload;
|
|
|
|
|
|
try {
|
|
|
|
|
|
const workerResponse: {
|
|
|
|
|
|
errors: Array<unknown>;
|
|
|
|
|
|
result: unknown;
|
|
|
|
|
|
} = yield call(evalWorker.request, EVAL_WORKER_ACTIONS.EVAL_EXPRESSION, {
|
|
|
|
|
|
expression: value,
|
|
|
|
|
|
});
|
|
|
|
|
|
const lintErrors = (workerResponse.errors || []).filter(
|
|
|
|
|
|
(error: any) => error.errorType !== PropertyEvaluationErrorType.LINT,
|
|
|
|
|
|
);
|
|
|
|
|
|
if (workerResponse.result) {
|
|
|
|
|
|
const validation = validate({ type }, workerResponse.result, {}, "");
|
|
|
|
|
|
if (!validation.isValid)
|
|
|
|
|
|
validation.messages?.map((message) => {
|
|
|
|
|
|
lintErrors.unshift({
|
|
|
|
|
|
...validation,
|
|
|
|
|
|
...{
|
|
|
|
|
|
errorType: PropertyEvaluationErrorType.VALIDATION,
|
|
|
|
|
|
errorMessage: message,
|
|
|
|
|
|
},
|
|
|
|
|
|
});
|
|
|
|
|
|
});
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
yield put(
|
|
|
|
|
|
setEvaluatedActionSelectorField({
|
|
|
|
|
|
id,
|
|
|
|
|
|
evaluatedValue: {
|
|
|
|
|
|
value: workerResponse.result as string,
|
|
|
|
|
|
errors: lintErrors,
|
|
|
|
|
|
},
|
|
|
|
|
|
}),
|
|
|
|
|
|
);
|
|
|
|
|
|
} catch (e) {
|
|
|
|
|
|
log.error(e);
|
|
|
|
|
|
Sentry.captureException(e);
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-12-07 09:45:18 +00:00
|
|
|
|
export function* updateReplayEntitySaga(
|
|
|
|
|
|
actionPayload: ReduxAction<{
|
|
|
|
|
|
entityId: string;
|
|
|
|
|
|
entity: Replayable;
|
|
|
|
|
|
entityType: ENTITY_TYPE;
|
|
|
|
|
|
}>,
|
|
|
|
|
|
) {
|
|
|
|
|
|
//Delay updates to replay object to not persist every keystroke
|
|
|
|
|
|
yield delay(REPLAY_DELAY);
|
|
|
|
|
|
const { entity, entityId, entityType } = actionPayload.payload;
|
2022-06-21 13:57:34 +00:00
|
|
|
|
const workerResponse: unknown = yield call(
|
2022-11-03 09:23:15 +00:00
|
|
|
|
evalWorker.request,
|
2022-06-21 13:57:34 +00:00
|
|
|
|
EVAL_WORKER_ACTIONS.UPDATE_REPLAY_OBJECT,
|
|
|
|
|
|
{
|
|
|
|
|
|
entityId,
|
|
|
|
|
|
entity,
|
|
|
|
|
|
entityType,
|
|
|
|
|
|
},
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
return workerResponse;
|
2021-12-07 09:45:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
export function* workerComputeUndoRedo(operation: string, entityId: string) {
|
2022-11-03 09:23:15 +00:00
|
|
|
|
const workerResponse: unknown = yield call(evalWorker.request, operation, {
|
2021-12-07 09:45:18 +00:00
|
|
|
|
entityId,
|
|
|
|
|
|
});
|
2022-06-21 13:57:34 +00:00
|
|
|
|
return workerResponse;
|
2021-12-07 09:45:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2022-01-06 10:49:01 +00:00
|
|
|
|
// Type to represent the state of the evaluation reducer
|
|
|
|
|
|
export interface FormEvaluationConfig
|
|
|
|
|
|
extends ReduxAction<FormEvalActionPayload> {
|
|
|
|
|
|
currentEvalState: FormEvaluationState;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// Function to trigger the form eval job in the worker
|
|
|
|
|
|
export function* evalFormConfig(formEvaluationConfigObj: FormEvaluationConfig) {
|
2022-06-21 13:57:34 +00:00
|
|
|
|
const workerResponse: unknown = yield call(
|
2022-11-03 09:23:15 +00:00
|
|
|
|
evalWorker.request,
|
2022-01-06 10:49:01 +00:00
|
|
|
|
EVAL_WORKER_ACTIONS.INIT_FORM_EVAL,
|
|
|
|
|
|
formEvaluationConfigObj,
|
|
|
|
|
|
);
|
2022-06-21 13:57:34 +00:00
|
|
|
|
|
|
|
|
|
|
return workerResponse;
|
2022-01-06 10:49:01 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-11-10 07:11:23 +00:00
|
|
|
|
export function* setAppVersionOnWorkerSaga(action: {
|
|
|
|
|
|
type: ReduxActionType;
|
|
|
|
|
|
payload: EvaluationVersion;
|
|
|
|
|
|
}) {
|
|
|
|
|
|
const version: EvaluationVersion = action.payload;
|
2022-11-03 09:23:15 +00:00
|
|
|
|
yield call(evalWorker.request, EVAL_WORKER_ACTIONS.SET_EVALUATION_VERSION, {
|
2021-11-10 07:11:23 +00:00
|
|
|
|
version,
|
|
|
|
|
|
});
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-10-21 04:25:32 +00:00
|
|
|
|
export default function* evaluationSagaListeners() {
|
2020-12-30 13:26:44 +00:00
|
|
|
|
yield take(ReduxActionTypes.START_EVALUATION);
|
|
|
|
|
|
while (true) {
|
|
|
|
|
|
try {
|
|
|
|
|
|
yield call(evaluationChangeListenerSaga);
|
|
|
|
|
|
} catch (e) {
|
|
|
|
|
|
log.error(e);
|
|
|
|
|
|
Sentry.captureException(e);
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
2020-10-21 04:25:32 +00:00
|
|
|
|
}
|
2022-12-21 17:14:47 +00:00
|
|
|
|
|
|
|
|
|
|
export { evalWorker as EvalWorker };
|