@checkstack/frontend-api 0.5.2 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +72 -0
- package/package.json +4 -4
- package/src/orpc-query.tsx +14 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,77 @@
|
|
|
1
1
|
# @checkstack/frontend-api
|
|
2
2
|
|
|
3
|
+
## 0.6.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- e2d6f25: feat(automation): connection picker for integration actions + restore Integrations menu
|
|
8
|
+
|
|
9
|
+
Connection-backed automation actions (Jira, Teams, Webex) now render a
|
|
10
|
+
working connection picker plus cascading provider dropdowns in the
|
|
11
|
+
visual editor, and the Integrations entry is back in the user menu.
|
|
12
|
+
|
|
13
|
+
**Contract.** `ActionDefinition` gained an optional
|
|
14
|
+
`connectionProviderId` (and it is surfaced on `ActionInfoSchema` and
|
|
15
|
+
mapped in the `listActions` router). It carries the integration
|
|
16
|
+
provider's fully-qualified id, derived from the provider plugin's own
|
|
17
|
+
`pluginMetadata.pluginId` (never a hardcoded string), so the editor
|
|
18
|
+
knows which provider backs an action's dropdowns and it matches the
|
|
19
|
+
`qualifiedId` the integration provider registry assigns.
|
|
20
|
+
|
|
21
|
+
**Providers.** Jira, Teams and Webex each export
|
|
22
|
+
`*_PROVIDER_LOCAL_ID` / `*_PROVIDER_QUALIFIED_ID`, register their
|
|
23
|
+
provider with the local id, and add a `CONNECTION_OPTIONS`
|
|
24
|
+
(`"connectionOptions"`) resolver name. Their `post_message` /
|
|
25
|
+
issue actions set `connectionProviderId` and expose `connectionId`
|
|
26
|
+
as an `x-options-resolver` dropdown instead of a hidden field.
|
|
27
|
+
|
|
28
|
+
**Frontend bridge.** A new `useConnectionOptionResolvers` hook
|
|
29
|
+
(`@checkstack/automation-frontend`, which now depends on
|
|
30
|
+
`@checkstack/integration-common`) turns an action's
|
|
31
|
+
`x-options-resolver` schema fields into live data: the
|
|
32
|
+
`connectionOptions` resolver lists the provider's connections via
|
|
33
|
+
`listConnections`, and every other resolver name is forwarded to
|
|
34
|
+
`getConnectionOptions` for the selected `connectionId`, passing the
|
|
35
|
+
live form values as `context` for dependent fields. `ProviderActionBody`
|
|
36
|
+
now passes this map to `DynamicForm` (it was previously missing
|
|
37
|
+
entirely, so connection-backed actions had no working dropdowns).
|
|
38
|
+
|
|
39
|
+
**frontend-api.** `usePluginClient` procedures now also expose a typed
|
|
40
|
+
imperative `.call(input)` alongside `.useQuery` / `.useMutation`, for
|
|
41
|
+
async callbacks that cannot host a hook (such as a `DynamicForm`
|
|
42
|
+
options resolver). Additive, non-breaking.
|
|
43
|
+
|
|
44
|
+
**Integrations menu.** Re-added `IntegrationMenuItem` and a new
|
|
45
|
+
`IntegrationsLandingPage`, wired into `integration-frontend` as a list
|
|
46
|
+
route and a `UserMenuItemsSlot` entry under the "Configuration" group.
|
|
47
|
+
|
|
48
|
+
**Action card polish.** The action editor's secondary metadata (id,
|
|
49
|
+
description, failure behaviour) is now grouped into one quiet settings
|
|
50
|
+
panel with consistent small uppercase "eyebrow" labels, so the action's
|
|
51
|
+
own configuration stays the focal point. The raw failure checkbox was
|
|
52
|
+
replaced with the standard `Checkbox` control, and the provider action
|
|
53
|
+
picker / configuration sections gained consistent section headers and a
|
|
54
|
+
divider. The per-step "type" dropdown was removed: an action's kind is
|
|
55
|
+
fixed at creation, so changing it now means adding a new step and
|
|
56
|
+
deleting the old one (avoids the surprising full-config reset that
|
|
57
|
+
switching kinds used to trigger).
|
|
58
|
+
|
|
59
|
+
**Add-step picker.** Adding a step now opens a Home-Assistant-style
|
|
60
|
+
dialog where the operator decides the step type up front: an "Actions"
|
|
61
|
+
tab lists the registered provider actions grouped by category
|
|
62
|
+
(searchable; picking one presets the step's `action`), and a "Blocks"
|
|
63
|
+
tab lists the structural building blocks (choose / parallel / repeat /
|
|
64
|
+
etc.). Because the concrete action is chosen here, the in-card action
|
|
65
|
+
switcher was removed - a step's action is fixed once created. Composite
|
|
66
|
+
blocks now start with an empty child list (filled via the nested
|
|
67
|
+
add-step picker) instead of seeding an unconfigurable empty action.
|
|
68
|
+
|
|
69
|
+
### Patch Changes
|
|
70
|
+
|
|
71
|
+
- Updated dependencies [6d52276]
|
|
72
|
+
- @checkstack/common@0.12.0
|
|
73
|
+
- @checkstack/signal-common@0.2.5
|
|
74
|
+
|
|
3
75
|
## 0.5.2
|
|
4
76
|
|
|
5
77
|
### Patch Changes
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@checkstack/frontend-api",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.6.0",
|
|
4
4
|
"license": "Elastic-2.0",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./src/index.ts",
|
|
@@ -13,8 +13,8 @@
|
|
|
13
13
|
"react": "^18.0.0"
|
|
14
14
|
},
|
|
15
15
|
"dependencies": {
|
|
16
|
-
"@checkstack/common": "0.
|
|
17
|
-
"@checkstack/signal-common": "0.2.
|
|
16
|
+
"@checkstack/common": "0.11.0",
|
|
17
|
+
"@checkstack/signal-common": "0.2.4",
|
|
18
18
|
"@orpc/client": "^1.13.14",
|
|
19
19
|
"@orpc/contract": "^1.13.14",
|
|
20
20
|
"@orpc/react-query": "1.13.4",
|
|
@@ -26,7 +26,7 @@
|
|
|
26
26
|
"@types/react": "^18.0.0",
|
|
27
27
|
"typescript": "^5.0.0",
|
|
28
28
|
"@checkstack/tsconfig": "0.0.7",
|
|
29
|
-
"@checkstack/scripts": "0.3.
|
|
29
|
+
"@checkstack/scripts": "0.3.3"
|
|
30
30
|
},
|
|
31
31
|
"checkstack": {
|
|
32
32
|
"type": "tooling"
|
package/src/orpc-query.tsx
CHANGED
|
@@ -89,6 +89,12 @@ interface QueryProcedure<TInput, TOutput> {
|
|
|
89
89
|
input?: TInput,
|
|
90
90
|
options?: Omit<UseQueryOptions<TOutput, Error>, "queryKey" | "queryFn">,
|
|
91
91
|
) => UseQueryResult<TOutput, Error>;
|
|
92
|
+
/**
|
|
93
|
+
* Imperative one-shot call, outside React Query. Use inside async
|
|
94
|
+
* callbacks that can't host a hook (e.g. a DynamicForm options
|
|
95
|
+
* resolver). Prefer `useQuery` for anything rendered.
|
|
96
|
+
*/
|
|
97
|
+
call: (input: TInput) => Promise<TOutput>;
|
|
92
98
|
}
|
|
93
99
|
|
|
94
100
|
/**
|
|
@@ -107,6 +113,12 @@ interface MutationProcedure<TInput, TOutput> {
|
|
|
107
113
|
"mutationFn" | "mutationKey"
|
|
108
114
|
>,
|
|
109
115
|
) => UseMutationResult<TOutput, Error, TInput, TContext>;
|
|
116
|
+
/**
|
|
117
|
+
* Imperative one-shot call, outside React Query. Use inside async
|
|
118
|
+
* callbacks that can't host a hook (e.g. a DynamicForm options
|
|
119
|
+
* resolver). Prefer `useMutation` for anything tied to UI lifecycle.
|
|
120
|
+
*/
|
|
121
|
+
call: (input: TInput) => Promise<TOutput>;
|
|
110
122
|
}
|
|
111
123
|
|
|
112
124
|
/**
|
|
@@ -355,6 +367,7 @@ function createProcedureHook<TInput, TOutput>(
|
|
|
355
367
|
const { onSuccess: _, ...restOptions } = options ?? {};
|
|
356
368
|
return useMutation({ ...mutationOpts, ...restOptions });
|
|
357
369
|
},
|
|
370
|
+
call: (input) => proc.call(input),
|
|
358
371
|
};
|
|
359
372
|
}
|
|
360
373
|
|
|
@@ -367,5 +380,6 @@ function createProcedureHook<TInput, TOutput>(
|
|
|
367
380
|
// Spread caller options AFTER to ensure they take precedence (e.g., enabled: false)
|
|
368
381
|
return useQuery({ ...queryOpts, ...options });
|
|
369
382
|
},
|
|
383
|
+
call: (input) => proc.call(input),
|
|
370
384
|
};
|
|
371
385
|
}
|