PromucFlow_constructor/app/client/src/selectors/templatesSelectors.tsx

220 lines
6.1 KiB
TypeScript
Raw Normal View History

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 { FilterKeys, Template } from "api/TemplatesApi";
2022-03-03 10:56:53 +00:00
import Fuse from "fuse.js";
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";
2022-03-03 10:56:53 +00:00
import { createSelector } from "reselect";
import { getWorkspaceCreateApplication } from "./applicationSelectors";
2022-03-10 14:39:05 +00:00
import { getWidgetCards } from "./editorSelectors";
2022-03-03 10:56:53 +00:00
import { getDefaultPlugins } from "./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 { Filter } from "pages/Templates/Filters";
2022-03-03 10:56:53 +00:00
const fuzzySearchOptions = {
keys: ["title", "id", "datasources", "widgets"],
2022-03-03 10:56:53 +00:00
shouldSort: true,
threshold: 0.5,
location: 0,
distance: 100,
};
export const getTemplatesSelector = (state: AppState) =>
state.ui.templates.templates;
export const isImportingTemplateSelector = (state: AppState) =>
state.ui.templates.isImportingTemplate;
export const isImportingTemplateToAppSelector = (state: AppState) =>
state.ui.templates.isImportingTemplateToApp;
2022-03-03 10:56:53 +00:00
export const showTemplateNotificationSelector = (state: AppState) =>
state.ui.templates.templateNotificationSeen;
export const getWorkspaceForTemplates = createSelector(
getWorkspaceCreateApplication,
(workspaceList) => {
if (workspaceList.length) {
return workspaceList[0];
2022-03-03 10:56:53 +00:00
}
return null;
},
);
export const getTemplateFilterSelector = (state: AppState) =>
state.ui.templates.filters;
export const getTemplateFiltersLength = createSelector(
getTemplateFilterSelector,
(filters) => {
return Object.values(filters)
.map((filterList) => filterList.length)
.reduce((c, a) => c + a, 0);
},
);
export const isFetchingTemplatesSelector = (state: AppState) =>
state.ui.templates.gettingAllTemplates;
2022-03-31 05:16:04 +00:00
export const isFetchingTemplateSelector = (state: AppState) =>
state.ui.templates.gettingTemplate;
2022-03-03 10:56:53 +00:00
export const getTemplateById = (id: string) => (state: AppState) => {
return state.ui.templates.templates.find((template) => template.id === id);
};
2022-03-31 05:16:04 +00:00
export const getActiveTemplateSelector = (state: AppState) =>
state.ui.templates.activeTemplate;
2022-03-03 10:56:53 +00:00
export const getFilteredTemplateList = createSelector(
getTemplatesSelector,
getTemplateFilterSelector,
2022-03-31 05:16:04 +00:00
getTemplateFiltersLength,
(templates, templatesFilters, numberOfFiltersApplied) => {
const result: Template[] = [];
const activeTemplateIds: string[] = [];
2022-03-31 05:16:04 +00:00
if (!numberOfFiltersApplied) {
return templates;
}
if (!Object.keys(templatesFilters).length) {
return templates;
2022-03-03 10:56:53 +00:00
}
2022-03-31 05:16:04 +00:00
Object.keys(templatesFilters).map((filter) => {
templates.map((template) => {
if (activeTemplateIds.includes(template.id)) {
return;
}
2022-03-31 05:16:04 +00:00
if (
template[filter as FilterKeys].some((templateFilter) => {
return templatesFilters[filter].includes(templateFilter);
})
) {
result.push(template);
activeTemplateIds.push(template.id);
2022-03-31 05:16:04 +00:00
}
});
});
return result;
2022-03-03 10:56:53 +00:00
},
);
export const getTemplateSearchQuery = (state: AppState) =>
state.ui.templates.templateSearchQuery;
export const getSearchedTemplateList = createSelector(
getFilteredTemplateList,
getTemplateSearchQuery,
(templates, query) => {
if (!query) {
return templates;
}
const fuzzy = new Fuse(templates, fuzzySearchOptions);
return fuzzy.search(query);
},
);
// Get the list of datasources which are used by templates
2022-03-03 10:56:53 +00:00
export const templatesDatasourceFiltersSelector = createSelector(
getTemplatesSelector,
2022-03-03 10:56:53 +00:00
getDefaultPlugins,
(templates, plugins) => {
const datasourceFilters: Filter[] = [];
templates.map((template) => {
template.datasources.map((pluginIdentifier) => {
if (
!datasourceFilters.find((filter) => filter.value === pluginIdentifier)
) {
const matchedPlugin = plugins.find(
(plugin) =>
plugin.id === pluginIdentifier ||
plugin.packageName === pluginIdentifier,
);
if (matchedPlugin) {
datasourceFilters.push({
label: matchedPlugin.name,
value: pluginIdentifier,
});
}
}
});
2022-03-03 10:56:53 +00:00
});
return datasourceFilters;
2022-03-03 10:56:53 +00:00
},
);
export const templatesFiltersSelector = (state: AppState) =>
state.ui.templates.allFilters;
2022-03-10 14:39:05 +00:00
// Get all filters which is associated with atleast one template
// If no template is associated with a filter, then the filter shouldn't be in the filter list
export const getFilterListSelector = createSelector(
getWidgetCards,
templatesDatasourceFiltersSelector,
getTemplatesSelector,
templatesFiltersSelector,
(widgetConfigs, allDatasources, templates, allTemplateFilters) => {
2022-03-10 14:39:05 +00:00
const filters: Record<string, Filter[]> = {
datasources: [],
functions: [],
2022-03-10 14:39:05 +00:00
};
const allFunctions = allTemplateFilters.functions.map((item) => {
2022-03-10 14:39:05 +00:00
return {
label: item,
value: item,
2022-03-10 14:39:05 +00:00
};
});
const filterFilters = (
key: "datasources" | "widgets" | "useCases" | "functions",
dataReference: Filter[],
template: Template,
) => {
template[key].map((templateValue) => {
if (
!filters[key].some((filter) => {
if (filter.value) {
return filter.value === templateValue;
}
return filter.label === templateValue;
})
) {
const filteredData = dataReference.find((datum) => {
if (datum.value) {
return datum.value === templateValue;
}
return datum.label === templateValue;
});
filteredData && filters[key].push(filteredData);
}
});
};
templates.map((template) => {
filterFilters("datasources", allDatasources, template);
filterFilters("functions", allFunctions, template);
2022-03-10 14:39:05 +00:00
});
return filters;
},
);
export const getForkableWorkspaces = createSelector(
getWorkspaceCreateApplication,
(workspaces) => {
return workspaces.map((workspace) => {
2022-03-03 10:56:53 +00:00
return {
label: workspace.workspace.name,
value: workspace.workspace.id,
2022-03-03 10:56:53 +00:00
};
});
},
);
export const templateModalOpenSelector = (state: AppState) =>
state.ui.templates.showTemplatesModal;
export const templatesCountSelector = (state: AppState) =>
state.ui.templates.templates.length;