#9137: types and migrations for mod variable declaration section (1/3) #9138
Conversation
src/types/modComponentTypes.ts
Outdated
| * | ||
| * @since 2.1.2 | ||
| */ | ||
| variables?: ModVariablesDefinition; |
There was a problem hiding this comment.
@grahamlangford @BLoe do you feel strongly about this being required? optionsArgs?, services?, definitions? are all optional
There was a problem hiding this comment.
The more we require, the simpler the typing is. But I don't feel strongly now that we have StrictNullChecks globally enabled
| @@ -101,6 +117,7 @@ export interface UnsavedModDefinition extends Definition { | |||
| extensionPoints: ModComponentDefinition[]; | |||
| definitions?: InnerDefinitions; | |||
| options?: ModOptionsDefinition; | |||
| variables?: ModVariablesDefinition; | |||
There was a problem hiding this comment.
Optional to avoid requiring backend/IDB migration. See discussion on activated mod component here: https://github.com/pixiebrix/pixiebrix-extension/pull/9138/files#r1755687124
Playwright test results
Details
Flaky testschrome › tests/pageEditor/addStarterBrick.spec.ts › Add starter brick to mod Skipped testschrome › tests/regressions/doNotCloseSidebarOnPageEditorSave.spec.ts › #8104: Do not automatically close the sidebar when saving in the Page Editor |
twschiller
changed the title
| * @see ModDefinition.variables | ||
| * @since 2.1.2 | ||
| */ | ||
| variablesDefinition: ModVariablesDefinition; |
There was a problem hiding this comment.
Why the mismatch between mod.variables and variablesDefinition on the formState?
There was a problem hiding this comment.
Matching the naming conventions for the 2 types:
Mod definition:
export interface UnsavedModDefinition extends Definition {
kind: typeof DefinitionKinds.MOD;
extensionPoints: ModComponentDefinition[];
definitions?: InnerDefinitions;
options?: ModOptionsDefinition;
variables?: ModVariablesDefinition;
}
Versus form state:
/**
* Information about the mod options or `undefined`
* if the mod component is not part of a mod.
* @see ModDefinition.options
*/
optionsDefinition?: ModOptionsDefinition;
/**
* The mod variable definitions/declarations
* @see ModDefinition.variables
* @since 2.1.2
*/
variablesDefinition: ModVariablesDefinition;
Personally, I'm indifferent. So if there's preference on where the team wants the naming to go, we should adopt it now to avoid having to write another migration in the future
There was a problem hiding this comment.
I think we should be migrating to a world where the formstate and the mod definition are as similar as possible (ideally a formstate would just be a mutable mod definition?). I would like to have @BLoe to weigh in though since he's spent the most time dealing with the form states in the Page Editor
There was a problem hiding this comment.
In general, I'd prefer to use the Definitions and Values suffixes everywhere possible to differentiate between the definitions and current values. I don't really care if we do that here/now or a DX change later that updates these all at once to add the suffix.
There was a problem hiding this comment.
In general, I'd prefer to use the Definitions and Values suffixes everywhere possible to differentiate between the definitions and current values
In ModDefinition, everything is definition. So using suffix on sub-properties would be redundant. Therefore, I wouldn't use the suffix there:
export interface UnsavedModDefinition extends Definition {
kind: typeof DefinitionKinds.MOD;
extensionPoints: ModComponentDefinition[];
definitions?: InnerDefinitions;
options?: ModOptionsDefinition;
variables?: ModVariablesDefinition;
}
I've updated the change in ModComponent clarify that it's the definition and not the variables themselves
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9138 +/- ##
==========================================
+ Coverage 74.24% 74.78% +0.53%
==========================================
Files 1332 1360 +28
Lines 40817 41925 +1108
Branches 7634 7829 +195
==========================================
+ Hits 30306 31354 +1048
- Misses 10511 10571 +60 ☔ View full report in Codecov by Sentry. |
twschiller
changed the title
|
@BLoe @grahamlangford this PR is ready for review |
| @@ -22,8 +22,7 @@ import { type IntegrationDependency } from "@/integrations/integrationTypes"; | |||
| import { PIXIEBRIX_INTEGRATION_ID } from "@/integrations/constants"; | |||
|
|
|||
| /** | |||
| * Infer options from existing mod-component-like instances for reinstalling a mod | |||
| * @see installRecipe | |||
There was a problem hiding this comment.
Broken reference
twschiller
changed the title
What does this PR do?
Discussion
variablesrequired on activated mod component?optionsArgs?,services?,definitions?are all optionalRemaining Work
For more information on our expectations for the PR process, see the
code review principles doc