Mirrored_Repos/InvokeAI
1
0
Fork 0
mirror of https://github.com/invoke-ai/InvokeAI synced 2024-08-30 20:32:17 +00:00
Code Issues Packages Projects Releases Wiki Activity
099082abc1
InvokeAI/invokeai/frontend/web/src/services/api/schema.d.ts

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

5713 lines
144 KiB
TypeScript
Raw Normal View History

feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
* This file was auto-generated by openapi-typescript.
* Do not make direct changes to the file.
*/
export type paths = {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/sessions/': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Sessions
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of sessions, optionally searching
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['list_sessions'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Create Session
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a new session, optionally initializing it with an invocation graph
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
post: operations['create_session'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/sessions/{session_id}': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Session
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a session
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['get_session'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/sessions/{session_id}/nodes': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Add Node
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Adds a node to the graph
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
post: operations['add_node'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/sessions/{session_id}/nodes/{node_path}': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Update Node
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Updates a node in the graph and removes all linked edges
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
put: operations['update_node'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Node
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes a node in the graph and removes all linked edges
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
delete: operations['delete_node'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/sessions/{session_id}/edges': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Add Edge
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Adds an edge to the graph
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
post: operations['add_edge'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/sessions/{session_id}/edges/{from_node_id}/{from_field}/{to_node_id}/{to_field}': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Edge
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes an edge from the graph
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
delete: operations['delete_edge'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/sessions/{session_id}/invoke': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Invoke Session
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Invokes a session
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
put: operations['invoke_session'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cancel Session Invoke
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Invokes a session
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
delete: operations['cancel_session_invoke'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/models/': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Models
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of models
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['list_models'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Import Model
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Add Model
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
post: operations['import_model'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/models/{model_name}': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Model
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Delete Model
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
delete: operations['del_model'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/images/': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Images With Metadata
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of images
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['list_images_with_metadata'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Upload Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Uploads an image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
post: operations['upload_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/images/{image_name}': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Full
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a full-resolution image file
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['get_image_full'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes an image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
delete: operations['delete_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Update Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Updates an image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
patch: operations['update_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/images/{image_name}/metadata': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Metadata
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets an image's metadata
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['get_image_metadata'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/images/{image_name}/thumbnail': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Thumbnail
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a thumbnail image file
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['get_image_thumbnail'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/images/{image_name}/urls': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Urls
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets an image and thumbnail URL
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['get_image_urls'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/boards/': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Boards
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of boards
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['list_boards'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Create Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a board
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
post: operations['create_board'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/boards/{board_id}': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a board
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['get_board'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes a board
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
delete: operations['delete_board'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Update Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Updates a board
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
patch: operations['update_board'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/board_images/': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Create Board Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a board_image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
post: operations['create_board_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Remove Board Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes a board_image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
delete: operations['remove_board_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'/api/v1/board_images/{board_id}': {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Board Images
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of images for a board
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
get: operations['list_board_images'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
export type webhooks = Record<string, never>;
export type components = {
schemas: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* AddInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Adds two numbers
*/
AddInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default add
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'add';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A
* @description The first number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
a?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* B
* @description The second number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
b?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* BaseModelType
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
BaseModelType: 'sd-1' | 'sd-2';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** BoardChanges */
BoardChanges: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Board Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The board's new name.
*/
board_name?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cover Image Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the board's new cover image.
*/
cover_image_name?: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* BoardDTO
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deserialized board record with cover image URL and image count.
*/
BoardDTO: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Board Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The unique ID of the board.
*/
board_id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Board Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the board.
*/
board_name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Created At
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The created timestamp of the board.
*/
created_at: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Updated At
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The updated timestamp of the board.
*/
updated_at: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Deleted At
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The deleted timestamp of the board.
*/
deleted_at?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cover Image Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the board's cover image.
*/
cover_image_name?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Count
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The number of images in the board.
*/
image_count: number;
};
/** Body_create_board_image */
Body_create_board_image: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Board Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of the board to add to
*/
board_id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the image to add
*/
image_name: string;
};
/** Body_remove_board_image */
Body_remove_board_image: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Board Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of the board
*/
board_id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the image to remove
*/
image_name: string;
};
/** Body_upload_image */
Body_upload_image: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* File
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* Format: binary
*/
file: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* CannyImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Canny edge detection for ControlNet
*/
CannyImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default canny_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'canny_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Low Threshold
* @description The low threshold of the Canny pixel gradient (0-255)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 100
*/
low_threshold?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* High Threshold
* @description The high threshold of the Canny pixel gradient (0-255)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 200
*/
high_threshold?: number;
};
/** CkptModelInfo */
CkptModelInfo: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Description
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A description of the model
*/
description?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the model
*/
model_name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The type of the model
*/
model_type: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Format
* @default ckpt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
format?: 'ckpt';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Config
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The path to the model config
*/
config: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Weights
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The path to the model weights
*/
weights: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The path to the model VAE
*/
vae: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width of the model
*/
width?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height of the model
*/
height?: number;
};
/** ClipField */
ClipField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Tokenizer
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Info to load tokenizer submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
tokenizer: components['schemas']['ModelInfo'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Text Encoder
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Info to load text_encoder submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
text_encoder: components['schemas']['ModelInfo'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Loras
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Loras to apply on model loading
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
loras: components['schemas']['LoraInfo'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* CollectInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Collects values into a collection
*/
CollectInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default collect
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'collect';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Item
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The item to collect (all inputs must be of the same type)
*/
item?: unknown;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The collection, will be provided on execution
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
collection?: unknown[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* CollectInvocationOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for all invocation outputs
*/
CollectInvocationOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default collect_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'collect_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The collection of input items
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
collection: unknown[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** ColorField */
ColorField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* R
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The red component
*/
r: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* G
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The green component
*/
g: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* B
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The blue component
*/
b: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The alpha component
*/
a: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* CompelInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Parse prompt using compel package to conditioning.
*/
CompelInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default compel
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'compel';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Prompt
* @description Prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default
*/
prompt?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Clip
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Clip to use
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
clip?: components['schemas']['ClipField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* CompelOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Compel parser output
*/
CompelOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default compel_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'compel_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Conditioning
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
conditioning?: components['schemas']['ConditioningField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** ConditioningField */
ConditioningField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Conditioning Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of conditioning data
*/
conditioning_name: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ContentShuffleImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies content shuffle processing to image
*/
ContentShuffleImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default content_shuffle_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'content_shuffle_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* H
* @description Content shuffle `h` parameter
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
h?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* W
* @description Content shuffle `w` parameter
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
w?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* F
* @description Content shuffle `f` parameter
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 256
*/
f?: number;
};
/** ControlField */
ControlField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The control image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control Model
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The ControlNet model to use
*/
control_model: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control Weight
* @description The weight given to the ControlNet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control_weight: number | number[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Begin Step Percent
* @description When the ControlNet is first applied (% of total steps)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
begin_step_percent: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* End Step Percent
* @description When the ControlNet is last applied (% of total steps)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
end_step_percent: number;
chore(ui): regen api schema
2023-06-25 04:04:16 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control Mode
* @description The control mode to use
* @default balanced
chore(ui): regen api schema
2023-06-25 04:04:16 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control_mode?: 'balanced' | 'more_prompt' | 'more_control' | 'unbalanced';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ControlNetInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Collects ControlNet info to pass to other nodes
*/
ControlNetInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default controlnet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'controlnet';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The control image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control Model
* @description control model used
* @default lllyasviel/sd-controlnet-canny
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control_model?:
| 'lllyasviel/sd-controlnet-canny'
| 'lllyasviel/sd-controlnet-depth'
| 'lllyasviel/sd-controlnet-hed'
| 'lllyasviel/sd-controlnet-seg'
| 'lllyasviel/sd-controlnet-openpose'
| 'lllyasviel/sd-controlnet-scribble'
| 'lllyasviel/sd-controlnet-normal'
| 'lllyasviel/sd-controlnet-mlsd'
| 'lllyasviel/control_v11p_sd15_canny'
| 'lllyasviel/control_v11p_sd15_openpose'
| 'lllyasviel/control_v11p_sd15_seg'
| 'lllyasviel/control_v11f1p_sd15_depth'
| 'lllyasviel/control_v11p_sd15_normalbae'
| 'lllyasviel/control_v11p_sd15_scribble'
| 'lllyasviel/control_v11p_sd15_mlsd'
| 'lllyasviel/control_v11p_sd15_softedge'
| 'lllyasviel/control_v11p_sd15s2_lineart_anime'
| 'lllyasviel/control_v11p_sd15_lineart'
| 'lllyasviel/control_v11p_sd15_inpaint'
| 'lllyasviel/control_v11e_sd15_shuffle'
| 'lllyasviel/control_v11e_sd15_ip2p'
| 'lllyasviel/control_v11f1e_sd15_tile'
| 'thibaud/controlnet-sd21-openpose-diffusers'
| 'thibaud/controlnet-sd21-canny-diffusers'
| 'thibaud/controlnet-sd21-depth-diffusers'
| 'thibaud/controlnet-sd21-scribble-diffusers'
| 'thibaud/controlnet-sd21-hed-diffusers'
| 'thibaud/controlnet-sd21-zoedepth-diffusers'
| 'thibaud/controlnet-sd21-color-diffusers'
| 'thibaud/controlnet-sd21-openposev2-diffusers'
| 'thibaud/controlnet-sd21-lineart-diffusers'
| 'thibaud/controlnet-sd21-normalbae-diffusers'
| 'thibaud/controlnet-sd21-ade20k-diffusers'
| 'CrucibleAI/ControlNetMediaPipeFace,diffusion_sd15'
| 'CrucibleAI/ControlNetMediaPipeFace';
/**
* Control Weight
* @description The weight given to the ControlNet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control_weight?: number | number[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Begin Step Percent
* @description When the ControlNet is first applied (% of total steps)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
begin_step_percent?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* End Step Percent
* @description When the ControlNet is last applied (% of total steps)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
end_step_percent?: number;
chore(ui): regen api schema
2023-06-25 04:04:16 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control Mode
* @description The control mode used
* @default balanced
chore(ui): regen api schema
2023-06-25 04:04:16 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control_mode?: 'balanced' | 'more_prompt' | 'more_control' | 'unbalanced';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** ControlNetModelConfig */
ControlNetModelConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'controlnet';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_format: components['schemas']['ControlNetModelFormat'];
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ControlNetModelFormat
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
ControlNetModelFormat: 'checkpoint' | 'diffusers';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ControlOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description node output for ControlNet info
*/
ControlOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default control_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'control_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The control info
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control?: components['schemas']['ControlField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** CreateModelRequest */
CreateModelRequest: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the model
*/
name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Info
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The model info
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
info:
| components['schemas']['CkptModelInfo']
| components['schemas']['DiffusersModelInfo'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* CvInpaintInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Simple inpaint using opencv.
*/
CvInpaintInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default cv_inpaint
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'cv_inpaint';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to inpaint
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mask
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The mask to use when inpainting
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
mask?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** DiffusersModelInfo */
DiffusersModelInfo: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Description
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A description of the model
*/
description?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the model
*/
model_name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The type of the model
*/
model_type: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Format
* @default folder
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
format?: 'folder';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The VAE repo to use for this model
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
vae?: components['schemas']['VaeRepo'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Repo Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The repo ID to use for this model
*/
repo_id?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Path
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The path to the model
*/
path?: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* DivideInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Divides two numbers
*/
DivideInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default div
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'div';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A
* @description The first number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
a?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* B
* @description The second number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
b?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* DynamicPromptInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Parses a prompt using adieyal/dynamicprompts' random or combinatorial generator
*/
DynamicPromptInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default dynamic_prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'dynamic_prompt';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The prompt to parse with dynamicprompts
*/
prompt: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Max Prompts
* @description The number of prompts to generate
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
max_prompts?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Combinatorial
* @description Whether to use the combinatorial generator
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
combinatorial?: boolean;
};
/** Edge */
Edge: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Source
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The connection for the edge's from node and field
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
source: components['schemas']['EdgeConnection'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Destination
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The connection for the edge's to node and field
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
destination: components['schemas']['EdgeConnection'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** EdgeConnection */
EdgeConnection: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Node Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of the node for this edge connection
*/
node_id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Field
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The field for this connection
*/
field: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* FloatCollectionOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A collection of floats
*/
FloatCollectionOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default float_collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'float_collection';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Collection
* @description The float collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default []
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
collection?: number[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* FloatLinearRangeInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a range
*/
FloatLinearRangeInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default float_range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'float_range';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Start
* @description The first value of the range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 5
*/
start?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Stop
* @description The last value of the range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 10
*/
stop?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Steps
* @description number of values to interpolate over (including start and stop)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 30
*/
steps?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* FloatOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A float output
*/
FloatOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default float_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'float_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Param
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output float
*/
param?: number;
};
/** Graph */
Graph: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this graph
*/
id?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Nodes
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The nodes in this graph
*/
nodes?: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
[key: string]:
| (
| components['schemas']['LoadImageInvocation']
| components['schemas']['ShowImageInvocation']
| components['schemas']['ImageCropInvocation']
| components['schemas']['ImagePasteInvocation']
| components['schemas']['MaskFromAlphaInvocation']
| components['schemas']['ImageMultiplyInvocation']
| components['schemas']['ImageChannelInvocation']
| components['schemas']['ImageConvertInvocation']
| components['schemas']['ImageBlurInvocation']
| components['schemas']['ImageResizeInvocation']
| components['schemas']['ImageScaleInvocation']
| components['schemas']['ImageLerpInvocation']
| components['schemas']['ImageInverseLerpInvocation']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['CvInpaintInvocation']
| components['schemas']['RestoreFaceInvocation']
| components['schemas']['MainModelLoaderInvocation']
| components['schemas']['LoraLoaderInvocation']
| components['schemas']['VaeLoaderInvocation']
| components['schemas']['CompelInvocation']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['ControlNetInvocation']
| components['schemas']['ImageProcessorInvocation']
| components['schemas']['TextToLatentsInvocation']
| components['schemas']['LatentsToImageInvocation']
| components['schemas']['ResizeLatentsInvocation']
| components['schemas']['ScaleLatentsInvocation']
| components['schemas']['ImageToLatentsInvocation']
| components['schemas']['InpaintInvocation']
| components['schemas']['AddInvocation']
| components['schemas']['SubtractInvocation']
| components['schemas']['MultiplyInvocation']
| components['schemas']['DivideInvocation']
| components['schemas']['RandomIntInvocation']
| components['schemas']['ParamIntInvocation']
| components['schemas']['ParamFloatInvocation']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['UpscaleInvocation']
| components['schemas']['RangeInvocation']
| components['schemas']['RangeOfSizeInvocation']
| components['schemas']['RandomRangeInvocation']
| components['schemas']['DynamicPromptInvocation']
| components['schemas']['InfillColorInvocation']
| components['schemas']['InfillTileInvocation']
| components['schemas']['InfillPatchMatchInvocation']
| components['schemas']['NoiseInvocation']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['FloatLinearRangeInvocation']
| components['schemas']['StepParamEasingInvocation']
| components['schemas']['GraphInvocation']
| components['schemas']['IterateInvocation']
| components['schemas']['CollectInvocation']
| components['schemas']['CannyImageProcessorInvocation']
| components['schemas']['HedImageProcessorInvocation']
| components['schemas']['LineartImageProcessorInvocation']
| components['schemas']['LineartAnimeImageProcessorInvocation']
| components['schemas']['OpenposeImageProcessorInvocation']
| components['schemas']['MidasDepthImageProcessorInvocation']
| components['schemas']['NormalbaeImageProcessorInvocation']
| components['schemas']['MlsdImageProcessorInvocation']
| components['schemas']['PidiImageProcessorInvocation']
| components['schemas']['ContentShuffleImageProcessorInvocation']
| components['schemas']['ZoeDepthImageProcessorInvocation']
| components['schemas']['MediapipeFaceProcessorInvocation']
| components['schemas']['LeresImageProcessorInvocation']
| components['schemas']['TileResamplerProcessorInvocation']
| components['schemas']['SegmentAnythingProcessorInvocation']
| components['schemas']['LatentsToLatentsInvocation']
)
| undefined;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Edges
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The connections between nodes and their fields in this graph
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
edges?: components['schemas']['Edge'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* GraphExecutionState
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Tracks the state of a graph execution
*/
GraphExecutionState: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of the execution state
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Graph
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The graph being executed
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
graph: components['schemas']['Graph'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Execution Graph
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The expanded graph of activated and executed nodes
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
execution_graph: components['schemas']['Graph'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Executed
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The set of node ids that have been executed
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
executed: string[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Executed History
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The list of node ids that have been executed, in order of execution
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
executed_history: string[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Results
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The results of node executions
*/
results: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
[key: string]:
| (
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['ImageOutput']
| components['schemas']['MaskOutput']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['ModelLoaderOutput']
| components['schemas']['LoraLoaderOutput']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['VaeLoaderOutput']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['CompelOutput']
| components['schemas']['ControlOutput']
| components['schemas']['LatentsOutput']
| components['schemas']['IntOutput']
| components['schemas']['FloatOutput']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['IntCollectionOutput']
| components['schemas']['FloatCollectionOutput']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['PromptOutput']
| components['schemas']['PromptCollectionOutput']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['NoiseOutput']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['GraphInvocationOutput']
| components['schemas']['IterateInvocationOutput']
| components['schemas']['CollectInvocationOutput']
)
| undefined;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Errors
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Errors raised when executing nodes
*/
errors: {
[key: string]: string | undefined;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Prepared Source Mapping
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The map of prepared nodes to original graph nodes
*/
prepared_source_mapping: {
[key: string]: string | undefined;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Source Prepared Mapping
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The map of original graph nodes to prepared nodes
*/
source_prepared_mapping: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
[key: string]: string[] | undefined;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* GraphInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Execute a graph
*/
GraphInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default graph
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'graph';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Graph
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The graph to run
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
graph?: components['schemas']['Graph'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* GraphInvocationOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for all invocation outputs
*/
GraphInvocationOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default graph_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'graph_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** HTTPValidationError */
HTTPValidationError: {
/** Detail */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
detail?: components['schemas']['ValidationError'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* HedImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies HED edge detection to image
*/
HedImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default hed_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'hed_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scribble
* @description Whether to use scribble mode
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
scribble?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageBlurInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Blurs an image
*/
ImageBlurInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_blur
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_blur';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to blur
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Radius
* @description The blur radius
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 8
*/
radius?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Blur Type
* @description The type of blur
* @default gaussian
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
blur_type?: 'gaussian' | 'box';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageCategory
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The category of an image.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
*
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* - GENERAL: The image is an output, init image, or otherwise an image without a specialized purpose.
* - MASK: The image is a mask image.
* - CONTROL: The image is a ControlNet control image.
* - USER: The image is a user-provide image.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* - OTHER: The image is some other type of image with a specialized purpose. To be used by external nodes.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
ImageCategory: 'general' | 'mask' | 'control' | 'user' | 'other';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageChannelInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a channel from an image.
*/
ImageChannelInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_chan
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_chan';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to get the channel from
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Channel
* @description The channel to get
* @default A
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
channel?: 'A' | 'R' | 'G' | 'B';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageCollectionInvocation
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description Load a collection of images and provide it as output.
*/
ImageCollectionInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default image_collection
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'image_collection';
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Images
* @description The image collection to load
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default []
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
images?: components['schemas']['ImageField'][];
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageCollectionOutput
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description A collection of images
*/
ImageCollectionOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default image_collection
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'image_collection';
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Collection
* @description The output images
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default []
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
collection: components['schemas']['ImageField'][];
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageConvertInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Converts an image to a different mode.
*/
ImageConvertInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_conv
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_conv';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to convert
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mode
* @description The mode to convert to
* @default L
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
mode?:
| 'L'
| 'RGB'
| 'RGBA'
| 'CMYK'
| 'YCbCr'
| 'LAB'
| 'HSV'
| 'I'
| 'F';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageCropInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Crops an image to a specified box. The box can be outside of the image.
*/
ImageCropInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_crop
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_crop';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to crop
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* X
* @description The left x coordinate of the crop rectangle
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
x?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Y
* @description The top y coordinate of the crop rectangle
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
y?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
* @description The width of the crop rectangle
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
width?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
* @description The height of the crop rectangle
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
height?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageDTO
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deserialized image record, enriched for the frontend.
*/
ImageDTO: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The unique name of the image.
*/
image_name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Url
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The URL of the image.
*/
image_url: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Thumbnail Url
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The URL of the image's thumbnail.
*/
thumbnail_url: string;
/** @description The type of the image. */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image_origin: components['schemas']['ResourceOrigin'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description The category of the image. */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image_category: components['schemas']['ImageCategory'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width of the image in px.
*/
width: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height of the image in px.
*/
height: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Created At
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The created timestamp of the image.
*/
created_at: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Updated At
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The updated timestamp of the image.
*/
updated_at: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Deleted At
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The deleted timestamp of the image.
*/
deleted_at?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Whether this is an intermediate image.
*/
is_intermediate: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Session Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The session ID that generated this image, if it is a generated image.
*/
session_id?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Node Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The node ID that generated this image, if it is a generated image.
*/
node_id?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Metadata
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A limited subset of the image's generation metadata. Retrieve the image's session for full metadata.
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
metadata?: components['schemas']['ImageMetadata'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Board Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of the board the image belongs to, if one exists.
*/
board_id?: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageField
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description An image field used for passing image objects between invocations
*/
ImageField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the image
*/
image_name: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageInverseLerpInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Inverse linear interpolation of all pixels of an image
*/
ImageInverseLerpInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_ilerp
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_ilerp';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to lerp
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Min
* @description The minimum input value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
min?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Max
* @description The maximum input value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 255
*/
max?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageLerpInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Linear interpolation of all pixels of an image
*/
ImageLerpInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_lerp
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_lerp';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to lerp
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Min
* @description The minimum output value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
min?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Max
* @description The maximum output value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 255
*/
max?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageMetadata
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Core generation metadata for an image/tensor generated in InvokeAI.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
*
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* Also includes any metadata from the image's PNG tEXt chunks.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
*
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* Generated by traversing the execution graph, collecting the parameters of the nearest ancestors
* of a given node.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
*
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* Full metadata may be accessed by querying for the session in the `graph_executions` table.
*/
ImageMetadata: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The type of the ancestor node of the image output node.
*/
type?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Positive Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The positive conditioning.
*/
positive_conditioning?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Negative Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The negative conditioning.
*/
negative_conditioning?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Width of the image/latents in pixels.
*/
width?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Height of the image/latents in pixels.
*/
height?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seed
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The seed used for noise generation.
*/
seed?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cfg Scale
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The classifier-free guidance scale.
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
cfg_scale?: number | number[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Steps
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The number of steps used for inference.
*/
steps?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scheduler
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The scheduler used for inference.
*/
scheduler?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The model used for inference.
*/
model?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Strength
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The strength used for image-to-image/latents-to-latents.
*/
strength?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Latents
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The ID of the initial latents.
*/
latents?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The VAE used for decoding.
*/
vae?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The UNet used dor inference.
*/
unet?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Clip
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The CLIP Encoder used for conditioning.
*/
clip?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Extra
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Uploaded image metadata, extracted from the PNG tEXt chunk.
*/
extra?: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageMultiplyInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Multiplies two images together using `PIL.ImageChops.multiply()`.
*/
ImageMultiplyInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_mul
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_mul';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image1
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The first image to multiply
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image1?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image2
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The second image to multiply
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image2?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for invocations that output an image
*/
ImageOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default image_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'image_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width of the image in pixels
*/
width: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height of the image in pixels
*/
height: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImagePasteInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Pastes an image into another image.
*/
ImagePasteInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_paste
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_paste';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Base Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The base image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to paste
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mask
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The mask to use when pasting
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
mask?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* X
* @description The left x coordinate at which to paste the image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
x?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Y
* @description The top y coordinate at which to paste the image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
y?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for invocations that preprocess images for ControlNet
*/
ImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageRecordChanges
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A set of changes to apply to an image record.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
*
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* Only limited changes are valid:
* - `image_category`: change the category of an image
* - `session_id`: change the session associated with an image
* - `is_intermediate`: change the image's `is_intermediate` flag
*/
ImageRecordChanges: {
/** @description The image's new category. */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image_category?: components['schemas']['ImageCategory'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Session Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image's new session ID.
*/
session_id?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image's new `is_intermediate` flag.
*/
is_intermediate?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageResizeInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Resizes an image to specific dimensions
*/
ImageResizeInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_resize
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_resize';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to resize
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width to resize to (px)
*/
width: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height to resize to (px)
*/
height: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Resample Mode
* @description The resampling mode
* @default bicubic
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
resample_mode?:
| 'nearest'
| 'box'
| 'bilinear'
| 'hamming'
| 'bicubic'
| 'lanczos';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageScaleInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Scales an image by a factor
*/
ImageScaleInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default img_scale
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'img_scale';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to scale
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scale Factor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The factor by which to scale the image
*/
scale_factor: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Resample Mode
* @description The resampling mode
* @default bicubic
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
resample_mode?:
| 'nearest'
| 'box'
| 'bilinear'
| 'hamming'
| 'bicubic'
| 'lanczos';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageToLatentsInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Encodes an image into latents.
*/
ImageToLatentsInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default i2l
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'i2l';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to encode
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Vae submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
vae?: components['schemas']['VaeField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Tiled
* @description Encode latents by overlaping tiles(less memory consumption)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
tiled?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ImageUrlsDTO
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The URLs for an image and its thumbnail.
*/
ImageUrlsDTO: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The unique name of the image.
*/
image_name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Url
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The URL of the image.
*/
image_url: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Thumbnail Url
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The URL of the image's thumbnail.
*/
thumbnail_url: string;
};
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/** ImportModelRequest */
ImportModelRequest: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Name
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description A model path, repo_id or URL to import
*/
name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Prediction Type
* @description Prediction type for SDv2 checkpoint files
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
prediction_type?: 'epsilon' | 'v_prediction' | 'sample';
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* InfillColorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Infills transparent areas of an image with a solid color
*/
InfillColorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default infill_rgba
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'infill_rgba';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to infill
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Color
* @description The color to use to infill
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default {
* "r": 127,
* "g": 127,
* "b": 127,
* "a": 255
* }
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
color?: components['schemas']['ColorField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* InfillPatchMatchInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Infills transparent areas of an image using the PatchMatch algorithm
*/
InfillPatchMatchInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default infill_patchmatch
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'infill_patchmatch';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to infill
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* InfillTileInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Infills transparent areas of an image with tiles of the image
*/
InfillTileInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default infill_tile
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'infill_tile';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to infill
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Tile Size
* @description The tile size (px)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 32
*/
tile_size?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seed
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The seed to use for tile generation (omit for random)
*/
seed?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* InpaintInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Generates an image using inpaint.
*/
InpaintInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default inpaint
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'inpaint';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Positive Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Positive conditioning for generation
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
positive_conditioning?: components['schemas']['ConditioningField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Negative Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Negative conditioning for generation
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
negative_conditioning?: components['schemas']['ConditioningField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seed
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The seed to use (omit for random)
*/
seed?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Steps
* @description The number of steps to use to generate the image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 30
*/
steps?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
* @description The width of the resulting image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
width?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
* @description The height of the resulting image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
height?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cfg Scale
* @description The Classifier-Free Guidance, higher values may result in a result closer to the prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 7.5
*/
cfg_scale?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scheduler
* @description The scheduler to use
* @default euler
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
scheduler?:
| 'ddim'
| 'ddpm'
| 'deis'
| 'lms'
| 'lms_k'
| 'pndm'
| 'heun'
| 'heun_k'
| 'euler'
| 'euler_k'
| 'euler_a'
| 'kdpm_2'
| 'kdpm_2_a'
| 'dpmpp_2s'
| 'dpmpp_2s_k'
| 'dpmpp_2m'
| 'dpmpp_2m_k'
| 'dpmpp_2m_sde'
| 'dpmpp_2m_sde_k'
| 'dpmpp_sde'
| 'dpmpp_sde_k'
| 'unipc';
/**
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description UNet model
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
unet?: components['schemas']['UNetField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Vae model
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
vae?: components['schemas']['VaeField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The input image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Strength
* @description The strength of the original image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.75
*/
strength?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Fit
* @description Whether or not the result should be fit to the aspect ratio of the input image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default true
*/
fit?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mask
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The mask
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
mask?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seam Size
* @description The seam inpaint size (px)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 96
*/
seam_size?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seam Blur
* @description The seam inpaint blur radius (px)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 16
*/
seam_blur?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seam Strength
* @description The seam inpaint strength
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.75
*/
seam_strength?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seam Steps
* @description The number of steps to use for seam inpaint
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 30
*/
seam_steps?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Tile Size
* @description The tile infill method size (px)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 32
*/
tile_size?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Infill Method
* @description The method used to infill empty regions (px)
* @default patchmatch
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
infill_method?: 'patchmatch' | 'tile' | 'solid';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Inpaint Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width of the inpaint region (px)
*/
inpaint_width?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Inpaint Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height of the inpaint region (px)
*/
inpaint_height?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Inpaint Fill
* @description The solid infill method color
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default {
* "r": 127,
* "g": 127,
* "b": 127,
* "a": 255
* }
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
inpaint_fill?: components['schemas']['ColorField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Inpaint Replace
* @description The amount by which to replace masked areas with latent noise
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
inpaint_replace?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* IntCollectionOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A collection of integers
*/
IntCollectionOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default int_collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'int_collection';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Collection
* @description The int collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default []
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
collection?: number[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* IntOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description An integer output
*/
IntOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default int_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'int_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output integer
*/
a?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* IterateInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Iterates over a list of items
*/
IterateInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default iterate
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'iterate';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The list of items to iterate over
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
collection?: unknown[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Index
* @description The index, will be provided on executed iterators
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
index?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* IterateInvocationOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Used to connect iteration outputs. Will be expanded to a specific output.
*/
IterateInvocationOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default iterate_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'iterate_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Item
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The item being iterated over
*/
item: unknown;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LatentsField
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A latents field used for passing latents between invocations
*/
LatentsField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Latents Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The name of the latents
*/
latents_name: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LatentsOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for invocations that output latents
*/
LatentsOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default latents_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'latents_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Latents
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output latents
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
latents?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width of the latents in pixels
*/
width: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height of the latents in pixels
*/
height: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LatentsToImageInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Generates an image from latents.
*/
LatentsToImageInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default l2i
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'l2i';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Latents
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The latents to generate an image from
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
latents?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Vae submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
vae?: components['schemas']['VaeField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Tiled
* @description Decode latents by overlaping tiles(less memory consumption)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
tiled?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LatentsToLatentsInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Generates latents using latents as base image.
*/
LatentsToLatentsInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default l2l
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'l2l';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Positive Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Positive conditioning for generation
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
positive_conditioning?: components['schemas']['ConditioningField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Negative Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Negative conditioning for generation
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
negative_conditioning?: components['schemas']['ConditioningField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Noise
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The noise to use
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
noise?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Steps
* @description The number of steps to use to generate the image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 10
*/
steps?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cfg Scale
* @description The Classifier-Free Guidance, higher values may result in a result closer to the prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 7.5
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
cfg_scale?: number | number[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scheduler
* @description The scheduler to use
* @default euler
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
scheduler?:
| 'ddim'
| 'ddpm'
| 'deis'
| 'lms'
| 'lms_k'
| 'pndm'
| 'heun'
| 'heun_k'
| 'euler'
| 'euler_k'
| 'euler_a'
| 'kdpm_2'
| 'kdpm_2_a'
| 'dpmpp_2s'
| 'dpmpp_2s_k'
| 'dpmpp_2m'
| 'dpmpp_2m_k'
| 'dpmpp_2m_sde'
| 'dpmpp_2m_sde_k'
| 'dpmpp_sde'
| 'dpmpp_sde_k'
| 'unipc';
/**
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description UNet submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
unet?: components['schemas']['UNetField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The control to use
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control?:
| components['schemas']['ControlField']
| components['schemas']['ControlField'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Latents
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The latents to use as a base image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
latents?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Strength
* @description The strength of the latents to use
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.7
*/
strength?: number;
};
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LeresImageProcessorInvocation
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description Applies leres processing to image
*/
LeresImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default leres_image_processor
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'leres_image_processor';
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Thr A
* @description Leres parameter `thr_a`
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default 0
*/
thr_a?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Thr B
* @description Leres parameter `thr_b`
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default 0
*/
thr_b?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Boost
* @description Whether to use boost mode
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default false
*/
boost?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default 512
*/
image_resolution?: number;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LineartAnimeImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies line art anime processing to image
*/
LineartAnimeImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default lineart_anime_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'lineart_anime_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LineartImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies line art processing to image
*/
LineartImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default lineart_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'lineart_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Coarse
* @description Whether to use coarse mode
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
coarse?: boolean;
};
/** LoRAModelConfig */
LoRAModelConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'lora';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_format: components['schemas']['LoRAModelFormat'];
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LoRAModelFormat
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
LoRAModelFormat: 'lycoris' | 'diffusers';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LoadImageInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Load an image and provide it as output.
*/
LoadImageInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default load_image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'load_image';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to load
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** LoraInfo */
LoraInfo: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Info to load submodel
*/
model_name: string;
/** @description Base model */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description Info to load submodel */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_type: components['schemas']['ModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description Info to load submodel */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
submodel?: components['schemas']['SubModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Weight
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Lora's weight which to use when apply to model
*/
weight: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LoraLoaderInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Apply selected lora to unet and text_encoder.
*/
LoraLoaderInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default lora_loader
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'lora_loader';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Lora Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Lora model name
*/
lora_name: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Weight
* @description With what weight to apply lora
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.75
*/
weight?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description UNet model for applying lora
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
unet?: components['schemas']['UNetField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Clip
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Clip model for applying lora
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
clip?: components['schemas']['ClipField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* LoraLoaderOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Model loader output
*/
LoraLoaderOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default lora_loader_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'lora_loader_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description UNet submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
unet?: components['schemas']['UNetField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Clip
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Tokenizer and text_encoder submodels
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
clip?: components['schemas']['ClipField'];
};
/**
* MainModelField
* @description Main model field
*/
MainModelField: {
/**
* Model Name
* @description Name of the model
*/
model_name: string;
/** @description Base model */
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* MainModelLoaderInvocation
* @description Loads a main model, outputting its submodels.
*/
MainModelLoaderInvocation: {
/**
* Id
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
* Is Intermediate
* @description Whether or not this node is an intermediate node.
* @default false
*/
is_intermediate?: boolean;
/**
* Type
* @default main_model_loader
* @enum {string}
*/
type?: 'main_model_loader';
/**
* Model
* @description The model to load
*/
model: components['schemas']['MainModelField'];
};
/**
* MaskFromAlphaInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Extracts the alpha channel of an image as a mask.
*/
MaskFromAlphaInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default tomask
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'tomask';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to create the mask from
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Invert
* @description Whether or not to invert the mask
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
invert?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* MaskOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for invocations that output a mask
*/
MaskOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default mask
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'mask';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mask
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output mask
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
mask: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width of the mask in pixels
*/
width?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height of the mask in pixels
*/
height?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* MediapipeFaceProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies mediapipe face processing to image
*/
MediapipeFaceProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default mediapipe_face_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'mediapipe_face_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Max Faces
* @description Maximum number of faces to detect
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
max_faces?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Min Confidence
* @description Minimum confidence for face detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.5
*/
min_confidence?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* MidasDepthImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies Midas depth processing to image
*/
MidasDepthImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default midas_depth_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'midas_depth_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A Mult
* @description Midas parameter `a_mult` (a = a_mult * PI)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 2
*/
a_mult?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Bg Th
* @description Midas parameter `bg_th`
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.1
*/
bg_th?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* MlsdImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies MLSD processing to image
*/
MlsdImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default mlsd_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'mlsd_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Thr V
* @description MLSD parameter `thr_v`
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.1
*/
thr_v?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Thr D
* @description MLSD parameter `thr_d`
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.1
*/
thr_d?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ModelError
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
ModelError: 'not_found';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** ModelInfo */
ModelInfo: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Name
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Info to load submodel
*/
model_name: string;
/** @description Base model */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description Info to load submodel */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_type: components['schemas']['ModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description Info to load submodel */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
submodel?: components['schemas']['SubModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ModelLoaderOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Model loader output
*/
ModelLoaderOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default model_loader_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'model_loader_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description UNet submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
unet?: components['schemas']['UNetField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Clip
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Tokenizer and text_encoder submodels
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
clip?: components['schemas']['ClipField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Vae submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
vae?: components['schemas']['VaeField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ModelType
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
ModelType: 'main' | 'vae' | 'lora' | 'controlnet' | 'embedding';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ModelVariantType
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
ModelVariantType: 'normal' | 'inpaint' | 'depth';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** ModelsList */
ModelsList: {
/** Models */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
models: (
| components['schemas']['StableDiffusion1ModelDiffusersConfig']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['StableDiffusion1ModelCheckpointConfig']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['VaeModelConfig']
| components['schemas']['LoRAModelConfig']
| components['schemas']['ControlNetModelConfig']
| components['schemas']['TextualInversionModelConfig']
| components['schemas']['StableDiffusion2ModelCheckpointConfig']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['StableDiffusion2ModelDiffusersConfig']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
)[];
};
/**
* MultiplyInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Multiplies two numbers
*/
MultiplyInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default mul
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'mul';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A
* @description The first number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
a?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* B
* @description The second number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
b?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* NoiseInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Generates latent noise.
*/
NoiseInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default noise
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'noise';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seed
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The seed to use
*/
seed?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
* @description The width of the resulting noise
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
width?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
* @description The height of the resulting noise
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
height?: number;
chore(ui): regen types
2023-06-27 03:57:41 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Use Cpu
* @description Use CPU for noise generation (for reproducible results across platforms)
chore(ui): regen types
2023-06-27 03:57:41 +00:00
* @default true
*/
use_cpu?: boolean;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* NoiseOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Invocation noise output
*/
NoiseOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default noise_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'noise_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Noise
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output noise
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
noise?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width of the noise in pixels
*/
width: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height of the noise in pixels
*/
height: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* NormalbaeImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies NormalBae processing to image
*/
NormalbaeImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default normalbae_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'normalbae_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* OffsetPaginatedResults[BoardDTO]
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Offset-paginated results
*/
OffsetPaginatedResults_BoardDTO_: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Items
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Items
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
items: components['schemas']['BoardDTO'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Offset
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Offset from which to retrieve items
*/
offset: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Limit
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Limit of items to get
*/
limit: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Total
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Total number of items in result
*/
total: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* OffsetPaginatedResults[ImageDTO]
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Offset-paginated results
*/
OffsetPaginatedResults_ImageDTO_: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Items
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Items
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
items: components['schemas']['ImageDTO'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Offset
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Offset from which to retrieve items
*/
offset: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Limit
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Limit of items to get
*/
limit: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Total
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Total number of items in result
*/
total: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* OpenposeImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies Openpose processing to image
*/
OpenposeImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default openpose_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'openpose_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Hand And Face
* @description Whether to use hands and face mode
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
hand_and_face?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* PaginatedResults[GraphExecutionState]
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Paginated results
*/
PaginatedResults_GraphExecutionState_: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Items
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Items
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
items: components['schemas']['GraphExecutionState'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Page
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Current Page
*/
page: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Pages
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Total number of pages
*/
pages: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Per Page
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Number of items per page
*/
per_page: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Total
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Total number of items in result
*/
total: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ParamFloatInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description A float parameter
*/
ParamFloatInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default param_float
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'param_float';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Param
* @description The float value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
param?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ParamIntInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description An integer parameter
*/
ParamIntInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default param_int
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'param_int';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A
* @description The integer value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
a?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* PidiImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies PIDI processing to image
*/
PidiImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default pidi_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'pidi_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Detect Resolution
* @description The pixel resolution for detection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
detect_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image Resolution
* @description The pixel resolution for the output image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 512
*/
image_resolution?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Safe
* @description Whether to use safe mode
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
safe?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scribble
* @description Whether to use scribble mode
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
scribble?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* PromptCollectionOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for invocations that output a collection of prompts
*/
PromptCollectionOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default prompt_collection_output
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'prompt_collection_output';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Prompt Collection
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output prompt collection
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
prompt_collection: string[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Count
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The size of the prompt collection
*/
count: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* PromptOutput
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Base class for invocations that output a prompt
*/
PromptOutput: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'prompt';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The output prompt
*/
prompt: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* RandomIntInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Outputs a single random integer.
*/
RandomIntInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default rand_int
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'rand_int';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Low
* @description The inclusive low value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
low?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* High
* @description The exclusive high value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 2147483647
*/
high?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* RandomRangeInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a collection of random numbers
*/
RandomRangeInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default random_range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'random_range';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Low
* @description The inclusive low value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
low?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* High
* @description The exclusive high value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 2147483647
*/
high?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Size
* @description The number of values to generate
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
size?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Seed
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The seed for the RNG (omit for random)
*/
seed?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* RangeInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a range of numbers from start to stop with step
*/
RangeInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'range';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Start
* @description The start of the range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
start?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Stop
* @description The stop of the range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 10
*/
stop?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Step
* @description The step of the range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
step?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* RangeOfSizeInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a range from start to start + size with step
*/
RangeOfSizeInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default range_of_size
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'range_of_size';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Start
* @description The start of the range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
start?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Size
* @description The number of values
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
size?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Step
* @description The step of the range
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
step?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ResizeLatentsInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Resizes latents to explicit width/height (in pixels). Provided dimensions are floor-divided by 8.
*/
ResizeLatentsInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default lresize
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'lresize';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Latents
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The latents to resize
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
latents?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Width
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The width to resize to (px)
*/
width: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Height
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The height to resize to (px)
*/
height: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mode
* @description The interpolation mode
* @default bilinear
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
mode?:
| 'nearest'
| 'linear'
| 'bilinear'
| 'bicubic'
| 'trilinear'
| 'area'
| 'nearest-exact';
/**
* Antialias
* @description Whether or not to antialias (applied in bilinear and bicubic modes only)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
antialias?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ResourceOrigin
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The origin of a resource (eg image).
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
*
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* - INTERNAL: The resource was created by the application.
* - EXTERNAL: The resource was not created by the application.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* This may be a user-initiated upload, or an internal application upload (eg Canvas init image).
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
ResourceOrigin: 'internal' | 'external';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* RestoreFaceInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Restores faces in an image.
*/
RestoreFaceInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default restore_face
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'restore_face';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The input image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Strength
* @description The strength of the restoration
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.75
*/
strength?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ScaleLatentsInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Scales latents by a given factor.
*/
ScaleLatentsInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default lscale
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'lscale';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Latents
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The latents to scale
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
latents?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scale Factor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The factor by which to scale the latents
*/
scale_factor: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mode
* @description The interpolation mode
* @default bilinear
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
mode?:
| 'nearest'
| 'linear'
| 'bilinear'
| 'bicubic'
| 'trilinear'
| 'area'
| 'nearest-exact';
/**
* Antialias
* @description Whether or not to antialias (applied in bilinear and bicubic modes only)
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
antialias?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* SegmentAnythingProcessorInvocation
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description Applies segment anything processing to image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
SegmentAnythingProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default segment_anything_processor
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'segment_anything_processor';
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ShowImageInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Displays a provided image, and passes it forward in the pipeline.
*/
ShowImageInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default show_image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'show_image';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to show
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** StableDiffusion1ModelCheckpointConfig */
StableDiffusion1ModelCheckpointConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'main';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Format
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_format: 'checkpoint';
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Vae */
vae?: string;
/** Config */
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
config: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
variant: components['schemas']['ModelVariantType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** StableDiffusion1ModelDiffusersConfig */
StableDiffusion1ModelDiffusersConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'main';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Format
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_format: 'diffusers';
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Vae */
vae?: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
variant: components['schemas']['ModelVariantType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** StableDiffusion2ModelCheckpointConfig */
StableDiffusion2ModelCheckpointConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'main';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Format
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_format: 'checkpoint';
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Vae */
vae?: string;
/** Config */
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
config: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
variant: components['schemas']['ModelVariantType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** StableDiffusion2ModelDiffusersConfig */
StableDiffusion2ModelDiffusersConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'main';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Model Format
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_format: 'diffusers';
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Vae */
vae?: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
variant: components['schemas']['ModelVariantType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* StepParamEasingInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Experimental per-step parameter easing for denoising steps
*/
StepParamEasingInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default step_param_easing
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'step_param_easing';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Easing
* @description The easing function to use
* @default Linear
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
easing?:
| 'Linear'
| 'QuadIn'
| 'QuadOut'
| 'QuadInOut'
| 'CubicIn'
| 'CubicOut'
| 'CubicInOut'
| 'QuarticIn'
| 'QuarticOut'
| 'QuarticInOut'
| 'QuinticIn'
| 'QuinticOut'
| 'QuinticInOut'
| 'SineIn'
| 'SineOut'
| 'SineInOut'
| 'CircularIn'
| 'CircularOut'
| 'CircularInOut'
| 'ExponentialIn'
| 'ExponentialOut'
| 'ExponentialInOut'
| 'ElasticIn'
| 'ElasticOut'
| 'ElasticInOut'
| 'BackIn'
| 'BackOut'
| 'BackInOut'
| 'BounceIn'
| 'BounceOut'
| 'BounceInOut';
/**
* Num Steps
* @description number of denoising steps
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 20
*/
num_steps?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Start Value
* @description easing starting value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
start_value?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* End Value
* @description easing ending value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
end_value?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Start Step Percent
* @description fraction of steps at which to start easing
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
start_step_percent?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* End Step Percent
* @description fraction of steps after which to end easing
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 1
*/
end_step_percent?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Pre Start Value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description value before easing start
*/
pre_start_value?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Post End Value
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description value after easing end
*/
post_end_value?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Mirror
* @description include mirror of easing function
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
mirror?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Show Easing Plot
* @description show easing plot
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
show_easing_plot?: boolean;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* SubModelType
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
SubModelType:
| 'unet'
| 'text_encoder'
| 'tokenizer'
| 'vae'
| 'scheduler'
| 'safety_checker';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* SubtractInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Subtracts two numbers
*/
SubtractInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default sub
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'sub';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* A
* @description The first number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
a?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* B
* @description The second number
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0
*/
b?: number;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* TextToLatentsInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Generates latents from conditionings.
*/
TextToLatentsInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default t2l
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 't2l';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Positive Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Positive conditioning for generation
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
positive_conditioning?: components['schemas']['ConditioningField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Negative Conditioning
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Negative conditioning for generation
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
negative_conditioning?: components['schemas']['ConditioningField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Noise
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The noise to use
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
noise?: components['schemas']['LatentsField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Steps
* @description The number of steps to use to generate the image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 10
*/
steps?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cfg Scale
* @description The Classifier-Free Guidance, higher values may result in a result closer to the prompt
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 7.5
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
cfg_scale?: number | number[];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scheduler
* @description The scheduler to use
* @default euler
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
scheduler?:
| 'ddim'
| 'ddpm'
| 'deis'
| 'lms'
| 'lms_k'
| 'pndm'
| 'heun'
| 'heun_k'
| 'euler'
| 'euler_k'
| 'euler_a'
| 'kdpm_2'
| 'kdpm_2_a'
| 'dpmpp_2s'
| 'dpmpp_2s_k'
| 'dpmpp_2m'
| 'dpmpp_2m_k'
| 'dpmpp_2m_sde'
| 'dpmpp_2m_sde_k'
| 'dpmpp_sde'
| 'dpmpp_sde_k'
| 'unipc';
/**
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description UNet submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
unet?: components['schemas']['UNetField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Control
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The control to use
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
control?:
| components['schemas']['ControlField']
| components['schemas']['ControlField'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/** TextualInversionModelConfig */
TextualInversionModelConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'embedding';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/** Model Format */
model_format: null;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* TileResamplerProcessorInvocation
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description Base class for invocations that preprocess images for ControlNet
*/
TileResamplerProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default tile_image_processor
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'tile_image_processor';
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Down Sampling Rate
* @description Down sampling rate
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
* @default 1
*/
down_sampling_rate?: number;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** UNetField */
UNetField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Unet
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Info to load unet submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
unet: components['schemas']['ModelInfo'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Scheduler
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Info to load scheduler submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
scheduler: components['schemas']['ModelInfo'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Loras
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Loras to apply on model loading
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
loras: components['schemas']['LoraInfo'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* UpscaleInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Upscales an image.
*/
UpscaleInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default upscale
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'upscale';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The input image
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Strength
* @description The strength
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default 0.75
*/
strength?: number;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Level
* @description The upscale level
* @default 2
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {integer}
*/
level?: 2 | 4;
};
add vae lodaer
2023-06-30 22:15:04 +00:00
/**
* VAEModelField
* @description Vae model field
*/
VAEModelField: {
/**
* Model Name
* @description Name of the model
*/
model_name: string;
/** @description Base model */
base_model: components['schemas']['BaseModelType'];
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** VaeField */
VaeField: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Vae
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Info to load vae submodel
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
vae: components['schemas']['ModelInfo'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
add vae lodaer
2023-06-30 22:15:04 +00:00
/**
* VaeLoaderInvocation
* @description Loads a VAE model, outputting a VaeLoaderOutput
*/
VaeLoaderInvocation: {
/**
* Id
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
* Is Intermediate
* @description Whether or not this node is an intermediate node.
* @default false
*/
is_intermediate?: boolean;
/**
* Type
* @default vae_loader
* @enum {string}
*/
type?: 'vae_loader';
/**
* Vae Model
* @description The VAE to load
*/
vae_model: components['schemas']['VAEModelField'];
};
/**
* VaeLoaderOutput
* @description Model loader output
*/
VaeLoaderOutput: {
/**
* Type
* @default vae_loader_output
* @enum {string}
*/
type?: 'vae_loader_output';
/**
* Vae
* @description Vae model
*/
vae?: components['schemas']['VaeField'];
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** VaeModelConfig */
VaeModelConfig: {
/** Name */
name: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type: 'vae';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** Path */
path: string;
/** Description */
description?: string;
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_format: components['schemas']['VaeModelFormat'];
error?: components['schemas']['ModelError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* VaeModelFormat
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
VaeModelFormat: 'checkpoint' | 'diffusers';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** VaeRepo */
VaeRepo: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Repo Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The repo ID to use for this VAE
*/
repo_id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Path
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The path to the VAE
*/
path?: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Subfolder
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The subfolder to use for this VAE
*/
subfolder?: string;
};
/** ValidationError */
ValidationError: {
/** Location */
loc: (string | number)[];
/** Message */
msg: string;
/** Error Type */
type: string;
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* ZoeDepthImageProcessorInvocation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Applies Zoe depth processing to image
*/
ZoeDepthImageProcessorInvocation: {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Id
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The id of this node. Must be unique among all nodes.
*/
id: string;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Is Intermediate
* @description Whether or not this node is an intermediate node.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Type
* @default zoe_depth_image_processor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
type?: 'zoe_depth_image_processor';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description The image to process
*/
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image?: components['schemas']['ImageField'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
add vae lodaer
2023-06-30 22:15:04 +00:00
* StableDiffusion2ModelFormat
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
add vae lodaer
2023-06-30 22:15:04 +00:00
StableDiffusion2ModelFormat: 'checkpoint' | 'diffusers';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
add vae lodaer
2023-06-30 22:15:04 +00:00
* StableDiffusion1ModelFormat
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* @description An enumeration.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @enum {string}
*/
add vae lodaer
2023-06-30 22:15:04 +00:00
StableDiffusion1ModelFormat: 'checkpoint' | 'diffusers';
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
responses: never;
parameters: never;
requestBodies: never;
headers: never;
pathItems: never;
};
export type external = Record<string, never>;
export type operations = {
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Sessions
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of sessions, optionally searching
*/
list_sessions: {
parameters: {
query?: {
/** @description The page of results to get */
page?: number;
/** @description The number of results per page */
per_page?: number;
/** @description The query string to search for */
query?: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['PaginatedResults_GraphExecutionState_'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Create Session
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a new session, optionally initializing it with an invocation graph
*/
create_session: {
requestBody?: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['Graph'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['GraphExecutionState'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Invalid json */
400: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Session
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a session
*/
get_session: {
parameters: {
path: {
/** @description The id of the session to get */
session_id: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['GraphExecutionState'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Session not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Add Node
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Adds a node to the graph
*/
add_node: {
parameters: {
path: {
/** @description The id of the session */
session_id: string;
};
};
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json':
| components['schemas']['LoadImageInvocation']
| components['schemas']['ShowImageInvocation']
| components['schemas']['ImageCropInvocation']
| components['schemas']['ImagePasteInvocation']
| components['schemas']['MaskFromAlphaInvocation']
| components['schemas']['ImageMultiplyInvocation']
| components['schemas']['ImageChannelInvocation']
| components['schemas']['ImageConvertInvocation']
| components['schemas']['ImageBlurInvocation']
| components['schemas']['ImageResizeInvocation']
| components['schemas']['ImageScaleInvocation']
| components['schemas']['ImageLerpInvocation']
| components['schemas']['ImageInverseLerpInvocation']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['CvInpaintInvocation']
| components['schemas']['RestoreFaceInvocation']
| components['schemas']['MainModelLoaderInvocation']
| components['schemas']['LoraLoaderInvocation']
| components['schemas']['VaeLoaderInvocation']
| components['schemas']['CompelInvocation']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['ControlNetInvocation']
| components['schemas']['ImageProcessorInvocation']
| components['schemas']['TextToLatentsInvocation']
| components['schemas']['LatentsToImageInvocation']
| components['schemas']['ResizeLatentsInvocation']
| components['schemas']['ScaleLatentsInvocation']
| components['schemas']['ImageToLatentsInvocation']
| components['schemas']['InpaintInvocation']
| components['schemas']['AddInvocation']
| components['schemas']['SubtractInvocation']
| components['schemas']['MultiplyInvocation']
| components['schemas']['DivideInvocation']
| components['schemas']['RandomIntInvocation']
| components['schemas']['ParamIntInvocation']
| components['schemas']['ParamFloatInvocation']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['UpscaleInvocation']
| components['schemas']['RangeInvocation']
| components['schemas']['RangeOfSizeInvocation']
| components['schemas']['RandomRangeInvocation']
| components['schemas']['DynamicPromptInvocation']
| components['schemas']['InfillColorInvocation']
| components['schemas']['InfillTileInvocation']
| components['schemas']['InfillPatchMatchInvocation']
| components['schemas']['NoiseInvocation']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['FloatLinearRangeInvocation']
| components['schemas']['StepParamEasingInvocation']
| components['schemas']['GraphInvocation']
| components['schemas']['IterateInvocation']
| components['schemas']['CollectInvocation']
| components['schemas']['CannyImageProcessorInvocation']
| components['schemas']['HedImageProcessorInvocation']
| components['schemas']['LineartImageProcessorInvocation']
| components['schemas']['LineartAnimeImageProcessorInvocation']
| components['schemas']['OpenposeImageProcessorInvocation']
| components['schemas']['MidasDepthImageProcessorInvocation']
| components['schemas']['NormalbaeImageProcessorInvocation']
| components['schemas']['MlsdImageProcessorInvocation']
| components['schemas']['PidiImageProcessorInvocation']
| components['schemas']['ContentShuffleImageProcessorInvocation']
| components['schemas']['ZoeDepthImageProcessorInvocation']
| components['schemas']['MediapipeFaceProcessorInvocation']
| components['schemas']['LeresImageProcessorInvocation']
| components['schemas']['TileResamplerProcessorInvocation']
| components['schemas']['SegmentAnythingProcessorInvocation']
| components['schemas']['LatentsToLatentsInvocation'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': string;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Invalid node or link */
400: never;
/** @description Session not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Update Node
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Updates a node in the graph and removes all linked edges
*/
update_node: {
parameters: {
path: {
/** @description The id of the session */
session_id: string;
/** @description The path to the node in the graph */
node_path: string;
};
};
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json':
| components['schemas']['LoadImageInvocation']
| components['schemas']['ShowImageInvocation']
| components['schemas']['ImageCropInvocation']
| components['schemas']['ImagePasteInvocation']
| components['schemas']['MaskFromAlphaInvocation']
| components['schemas']['ImageMultiplyInvocation']
| components['schemas']['ImageChannelInvocation']
| components['schemas']['ImageConvertInvocation']
| components['schemas']['ImageBlurInvocation']
| components['schemas']['ImageResizeInvocation']
| components['schemas']['ImageScaleInvocation']
| components['schemas']['ImageLerpInvocation']
| components['schemas']['ImageInverseLerpInvocation']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['CvInpaintInvocation']
| components['schemas']['RestoreFaceInvocation']
| components['schemas']['MainModelLoaderInvocation']
| components['schemas']['LoraLoaderInvocation']
| components['schemas']['VaeLoaderInvocation']
| components['schemas']['CompelInvocation']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['ControlNetInvocation']
| components['schemas']['ImageProcessorInvocation']
| components['schemas']['TextToLatentsInvocation']
| components['schemas']['LatentsToImageInvocation']
| components['schemas']['ResizeLatentsInvocation']
| components['schemas']['ScaleLatentsInvocation']
| components['schemas']['ImageToLatentsInvocation']
| components['schemas']['InpaintInvocation']
| components['schemas']['AddInvocation']
| components['schemas']['SubtractInvocation']
| components['schemas']['MultiplyInvocation']
| components['schemas']['DivideInvocation']
| components['schemas']['RandomIntInvocation']
| components['schemas']['ParamIntInvocation']
| components['schemas']['ParamFloatInvocation']
add vae lodaer
2023-06-30 22:15:04 +00:00
| components['schemas']['UpscaleInvocation']
| components['schemas']['RangeInvocation']
| components['schemas']['RangeOfSizeInvocation']
| components['schemas']['RandomRangeInvocation']
| components['schemas']['DynamicPromptInvocation']
| components['schemas']['InfillColorInvocation']
| components['schemas']['InfillTileInvocation']
| components['schemas']['InfillPatchMatchInvocation']
| components['schemas']['NoiseInvocation']
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
| components['schemas']['FloatLinearRangeInvocation']
| components['schemas']['StepParamEasingInvocation']
| components['schemas']['GraphInvocation']
| components['schemas']['IterateInvocation']
| components['schemas']['CollectInvocation']
| components['schemas']['CannyImageProcessorInvocation']
| components['schemas']['HedImageProcessorInvocation']
| components['schemas']['LineartImageProcessorInvocation']
| components['schemas']['LineartAnimeImageProcessorInvocation']
| components['schemas']['OpenposeImageProcessorInvocation']
| components['schemas']['MidasDepthImageProcessorInvocation']
| components['schemas']['NormalbaeImageProcessorInvocation']
| components['schemas']['MlsdImageProcessorInvocation']
| components['schemas']['PidiImageProcessorInvocation']
| components['schemas']['ContentShuffleImageProcessorInvocation']
| components['schemas']['ZoeDepthImageProcessorInvocation']
| components['schemas']['MediapipeFaceProcessorInvocation']
| components['schemas']['LeresImageProcessorInvocation']
| components['schemas']['TileResamplerProcessorInvocation']
| components['schemas']['SegmentAnythingProcessorInvocation']
| components['schemas']['LatentsToLatentsInvocation'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['GraphExecutionState'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Invalid node or link */
400: never;
/** @description Session not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Node
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes a node in the graph and removes all linked edges
*/
delete_node: {
parameters: {
path: {
/** @description The id of the session */
session_id: string;
/** @description The path to the node to delete */
node_path: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['GraphExecutionState'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Invalid node or link */
400: never;
/** @description Session not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Add Edge
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Adds an edge to the graph
*/
add_edge: {
parameters: {
path: {
/** @description The id of the session */
session_id: string;
};
};
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['Edge'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['GraphExecutionState'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Invalid node or link */
400: never;
/** @description Session not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Edge
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes an edge from the graph
*/
delete_edge: {
parameters: {
path: {
/** @description The id of the session */
session_id: string;
/** @description The id of the node the edge is coming from */
from_node_id: string;
/** @description The field of the node the edge is coming from */
from_field: string;
/** @description The id of the node the edge is going to */
to_node_id: string;
/** @description The field of the node the edge is going to */
to_field: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['GraphExecutionState'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Invalid node or link */
400: never;
/** @description Session not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Invoke Session
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Invokes a session
*/
invoke_session: {
parameters: {
query?: {
/** @description Whether or not to invoke all remaining invocations */
all?: boolean;
};
path: {
/** @description The id of the session to invoke */
session_id: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description The invocation is queued */
202: never;
/** @description The session has no invocations ready to invoke */
400: never;
/** @description Session not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Cancel Session Invoke
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Invokes a session
*/
cancel_session_invoke: {
parameters: {
path: {
/** @description The id of the session to cancel */
session_id: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description The invocation is canceled */
202: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Models
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of models
*/
list_models: {
parameters: {
query?: {
/** @description Base model */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
base_model?: components['schemas']['BaseModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description The type of model to get */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
model_type?: components['schemas']['ModelType'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['ModelsList'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Import Model
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Add Model
*/
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
import_model: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['ImportModelRequest'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Model
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Delete Model
*/
del_model: {
parameters: {
path: {
model_name: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Model deleted successfully */
204: never;
/** @description Model not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Images With Metadata
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of images
*/
list_images_with_metadata: {
parameters: {
query?: {
/** @description The origin of images to list */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image_origin?: components['schemas']['ResourceOrigin'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description The categories of image to include */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
categories?: components['schemas']['ImageCategory'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description Whether to list intermediate images */
is_intermediate?: boolean;
/** @description The board id to filter by */
board_id?: string;
/** @description The page offset */
offset?: number;
/** @description The number of images per page */
limit?: number;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['OffsetPaginatedResults_ImageDTO_'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Upload Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Uploads an image
*/
upload_image: {
parameters: {
query: {
/** @description The category of the image */
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
image_category: components['schemas']['ImageCategory'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/** @description Whether this is an intermediate image */
is_intermediate: boolean;
/** @description The session ID associated with this upload, if any */
session_id?: string;
};
};
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'multipart/form-data': components['schemas']['Body_upload_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description The image was uploaded successfully */
201: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['ImageDTO'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Image upload failed */
415: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Full
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a full-resolution image file
*/
get_image_full: {
parameters: {
path: {
/** @description The name of full-resolution image file to get */
image_name: string;
};
};
responses: {
/** @description Return the full-resolution image */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'image/png': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Image not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes an image
*/
delete_image: {
parameters: {
path: {
/** @description The name of the image to delete */
image_name: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Update Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Updates an image
*/
update_image: {
parameters: {
path: {
/** @description The name of the image to update */
image_name: string;
};
};
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['ImageRecordChanges'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['ImageDTO'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Metadata
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets an image's metadata
*/
get_image_metadata: {
parameters: {
path: {
/** @description The name of image to get */
image_name: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['ImageDTO'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Thumbnail
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a thumbnail image file
*/
get_image_thumbnail: {
parameters: {
path: {
/** @description The name of thumbnail image file to get */
image_name: string;
};
};
responses: {
/** @description Return the image thumbnail */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'image/webp': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Image not found */
404: never;
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Image Urls
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets an image and thumbnail URL
*/
get_image_urls: {
parameters: {
path: {
/** @description The name of the image whose URL to get */
image_name: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['ImageUrlsDTO'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Boards
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of boards
*/
list_boards: {
parameters: {
query?: {
/** @description Whether to list all boards */
all?: boolean;
/** @description The page offset */
offset?: number;
/** @description The number of boards per page */
limit?: number;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json':
| components['schemas']['OffsetPaginatedResults_BoardDTO_']
| components['schemas']['BoardDTO'][];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Create Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a board
*/
create_board: {
parameters: {
query: {
/** @description The name of the board to create */
board_name: string;
};
};
responses: {
/** @description The board was created successfully */
201: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['BoardDTO'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Get Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a board
*/
get_board: {
parameters: {
path: {
/** @description The id of board to get */
board_id: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['BoardDTO'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Delete Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes a board
*/
delete_board: {
parameters: {
feat(ui): add multi-select and batch capabilities This introduces the core functionality for batch operations on images and multiple selection in the gallery/batch manager. A number of other substantial changes are included: - `imagesSlice` is consolidated into `gallerySlice`, allowing for simpler selection of filtered images - `batchSlice` is added to manage the batch - The wonky context pattern for image deletion has been changed, much simpler now using a `imageDeletionSlice` and redux listeners; this needs to be implemented still for the other image modals - Minimum gallery size in px implemented as a hook - Many style fixes & several bug fixes TODO: - The UI and UX need to be figured out, especially for controlnet - Batch processing is not hooked up; generation does not do anything with batch - Routes to support batch image operations, specifically delete and add/remove to/from boards
2023-07-03 14:09:18 +00:00
query?: {
/** @description Permanently delete all images on the board */
include_images?: boolean;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
path: {
/** @description The id of board to delete */
board_id: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Update Board
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Updates a board
*/
update_board: {
parameters: {
path: {
/** @description The id of board to update */
board_id: string;
};
};
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['BoardChanges'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description The board was updated successfully */
201: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['BoardDTO'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Create Board Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Creates a board_image
*/
create_board_image: {
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['Body_create_board_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description The image was added to a board successfully */
201: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* Remove Board Image
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Deletes a board_image
*/
remove_board_image: {
requestBody: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['Body_remove_board_image'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
responses: {
/** @description The image was removed from the board successfully */
201: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': unknown;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
/**
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* List Board Images
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
* @description Gets a list of images for a board
*/
list_board_images: {
parameters: {
query?: {
/** @description The page offset */
offset?: number;
/** @description The number of boards per page */
limit?: number;
};
path: {
/** @description The id of the board */
board_id: string;
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['OffsetPaginatedResults_ImageDTO_'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
'application/json': components['schemas']['HTTPValidationError'];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
};
Reference in New Issue Copy Permalink